めちゃくちゃハマったので、ここに記載

現行サーバのOSの期限が近付いたため、サーバの移行が行われました。
それにともない、DB（MySQL）も、地味にバージョンアップが実施された。

マイナーバージョンアップにより、SQLが厳密化され、型が違うカラムをJOINの条件にしていた部分をCONVERT()関数をつかって、キャストしたり。。。
CONVERT(数値カラム USING binary)=文字列カラム　みたいな。。。
型を意識しないで結合して作った奴出て来いよ！と思いつつ

それ以外は、プログラムの変更は行われていないのに、サーバ移行が行われ、パフォーマンスが大幅にダウン
その原因究明に、駆り出され、１週間

EXPLAINなどつけて、インデックス状況を確認し、SQLをチューニングしたり
でも、チューニングの結果が出ないの繰り返し。

幸いにも、旧サーバが残っていたので、新旧を比べることに。

新サーバのほうで、今まで使っていたインデックスが効いていない！
なんでだ？なんでだ？と試行錯誤。
（移管した奴が調べろよっと思いつつ、ストレスが溜まる１週間）

推測はインデックスが壊れているでは？、インデックスの統計情報がおかしいのでは？
と思いつつ、壊れているパターンから調査。
壊れてはいなそう。。。ということで、統計情報を確認。

差がありました。。。

確認したSQLとして、
SELECT database_name , table_name , last_update , stat_value , index_name ,
(stat_value * @@innodb_page_size) / 1024 / 1024 as size_mb
FROM mysql.innodb_index_stats
WHERE database_name='データベース名' AND table_name='テーブル名' AND stat_name='size';

結果：size_mbが全然違うじゃん！

ということで、

ANALYZE TABLE テーブル名　を実施

再度、サイズを確認し、更新されたことを確認
プログラムを動かしてみてくれ～とお願いしたら、１秒でレスポンスが返ってきた！と
苦労が報われるお返事がきました。

めちゃくちゃハマったというか、時間を使った。。。

[0回]