我的數據庫中有一個字段，大部分時間，區分大小寫無關緊要。強制查詢中的二進制文件
但是在某些情況下並非如此。
這樣的選項，因爲我看到它是，二進制關鍵字添加到查詢
select id from table where BINARY fieldname= 'tesT'
或更改表，使之成爲區分大小寫場。
問題是，使用BINARY關鍵字會導致查詢的額外開銷，或者這可以忽略不計。
update table set field='tesT' where BINARY anotherfield='4Rtrtactually '
簡短的回答是二進制文件已經以類似SO question推薦（它實際上將在聲明中更新中使用），但是開銷是否是可以忽略不計依賴於其他地區。
第一部分是你如何定義微不足道。如果你的意思是表現，然後定義你可以忽略的閾值返回時間（秒），並嘗試使用二進制選擇，而不是使用二進制來看看你得到什麼樣的返回時間（這些需要案件無關緊要的情況下）。此外，通過做一個解釋來消除任何差異。
第二部分是依賴於表有多大以及where子句列是如何索引的。一般來說，行數越多，則任何差異就越顯着。所以，如果你在查看錶中的十條記錄，那麼可能沒有任何事情給你做單個表更新。一千萬條記錄更容易引起注意。
第三部分是基於Yann Neuhaus在MSQL 5.7 reference guide中的評論。它可能取決於你在哪裏放置二進制關鍵字。假設他的發現是準確的，那麼將二進制代碼放在等號的不變側可能會更快（或者至少不同）。因此，測試您更新到重寫：
update table set field='tesT' where anotherfield = BINARY '4Rtrtactually '
說實話，我有我的這個第三部分疑慮，但我已經看到了怪異的MySQL魔力。有點好奇，如果你測試一下你的場景會有什麼結果。
最後一部分可能是您正在使用的排序規則類型。根據您的問題，您似乎正在使用不區分大小寫的排序規則。根據您使用這些數據的方式，您可能需要查看區分大小寫或二進制排序規則。這個SO question在這方面對我很有教育意義。