Mysql 5.6の「暗黙的な変換」により、インデックスの障害と不正確なデータが発生しました

バックグラウンド

SQlクエリ中に、where条件のvacharタイプフィールドの単一引用符クエリを削除しようとしましたが、この時点で、高速であるはずのこの文は実際には非常に遅いことがわかりました。このvarcharフィールドには複合インデックスがあります。アイテムの総数は58,989であり、一重引用符なしで見つかったデータでさえ、必要なデータではありません。
mysql 5.6バージョン、innoDBエンジンを使用

ここに写真の説明を挿入

SQLステートメントに一重引用符が導入されているということは、このタイプが文字列データタイプのCHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM、およびSETであることを意味します。。
一重引用符がない場合は、これがint、bigDecimalなどの文字列以外のタイプであることを意味します。
サブタイトルと特殊記号の文字列に一重引用符が追加されていない場合、結果として型変換が失敗し、SQlを実行できなくなります。上記のように：

1054 - Unknown column '000w1993521' in 'where clause', Time: 0.008000s

（ネットマップ）

最初に結論に達しました。インデックスフィールドで関数操作を実行すると（この場合、キャスト関数は暗黙的な変換を実行します）、インデックス値の順序が破壊される可能性があるため、オプティマイザーはツリー検索関数を破棄することを決定します。（Https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html）
[外部リンク画像の転送に失敗しました。ソースサイトにリーチ防止リンクメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします（img -l5AwT0xu-1607244327891）（http://note.youdao.com/yws/res/23689/CE6F785994E6476D816B23787CE65217）]の
意味：BINARY、CAST（）、またはCONVERT（）を使用してインデックス列を変換する場合は、MySQLインデックスが有効に使用されていない可能性があります。
検出されたデータの不正確さは、暗黙の変換によるものでもあり、変換後に異なる数値タイプが生成され、不等式が等しくなります。

上記の例は、他の状況に属する整数と文字列の比較です。次に、最初にインデックスの失敗の理由を分析しましょう
1. 暗黙的な変換の他のケースのため、比較値は比較のために浮動小数点数に変換する必要があります
2. 最初にクエリ条件の値を浮動小数点数に変換してから、テーブルのレコード値を変換します。これにより、この時間より前に作成されたインデックスの並べ替えは有効になりません。暗黙の変換（関数）によって元の値が変更されたため、オプティマイザはここではインデックスを直接使用せず、テーブル全体のスキャンを直接使用すると言われています。
上記のクエリ結果のように、一致しない値（または部分的に一致する値）をクエリします。これは、MYsqlの暗黙的な変換ルールであるソースコードを実際に確認する必要があります。ここでは詳しく分析しません（関連するドキュメントが見つからないため）。
歴史的な理由から、古いデザインとの互換性が必要です。MySQLの型変換関数castおよびconvertを使用して、明示的に変換できます。

暗黙的な変換と関数を使用すると、インデックスに障害が発生し、選択したデータが不正確になります
暗黙的な変換の条件とルール
暗黙的な変換が原因でインデックスが失敗する具体的な理由は、比較値を型変換する必要があり、インデックスが無効であるためです。
暗黙的な型変換は避けてください。暗黙的な変換の種類には、主に一貫性のないフィールドタイプが含まれ、パラメータには複数の型、文字セットタイプ、または一貫性のない照合ルールなどが含まれます。