質問: S AND deleted != 1 ORDER BY hoge_count DESC LIMIT N; ``` テーブル情報 `$show create table hoge` ``` CREATE TABLE `hoge` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `title` text, `user_id` int(10) unsigned DEFAULT NULL, `category` text, `date` datetime DEFAULT NULL, `deleted` tinyint(1) DEFAULT '0', `hoge_count` int(10) unsigned DEFAULT '0', PRIMARY KEY (`id`), KEY `index_user_id` (`user_id`), KEY `index_category` (`category`(255)), KEY `index_date` (`date`), KEY `index_deleted` (`deleted`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ``` ### 試したこと 以下のようなインデックスを追加しましたが、EXPLAINしても利用されていないようです ``` alter table hoge add index index_date_category_deleted_hoge_count(date, category(255), deleted, hoge_count) ``` ### 補足情報 Aurora MySQL 5.6.10a #### hogeテーブルの全件のレコード数 3,000,000件程度 #### 検索条件で取得できるレコード数(LIMITを除く) 6,000件程度 #### 各カラムのデータのバラつき deleted => 1:10 category => だいたい1/7で7つに分布
回答: 情報が少なすぎて有効なインデックスか精査しきれませんが、 LIMITの値が極端に小さい場合は、 `hoge_count`単体にインデックスを貼ると改善するかもしれません。 `date`と`category`と`deleted`は、 `hoge`テーブルの50%以上のレコードに当たるのであれば、 インデックスを利用しない可能性が高い。 テーブルをフルスキャンしてもそう変わらないとオプティマイザが判断します。 必要な情報としては * `hoge`テーブルの全件のレコード数 * 検索条件で取得できるレコード数(LIMITを除く) * 各カラムのデータのバラつき くらいが分かると、もう少し詳細な検討が可能です。