問題描述

CREATE TABLE test (id int(11) NOT NULL AUTO_INCREMENT COMMENT ’主鍵ID’,creator varchar(128) NOT NULL DEFAULT ’0’ COMMENT ’創(chuàng)建人’,gmt_create timestamp NULL DEFAULT NULL COMMENT ’創(chuàng)建時間’,modifier varchar(128) DEFAULT ’0’ COMMENT ’修改人’,gmt_modified timestamp NULL DEFAULT NULL COMMENT ’修改時間’,title varchar(64) DEFAULT NULL COMMENT ’工單標題’,category varchar(32) DEFAULT NULL COMMENT ’工單類別’,subject varchar(32) DEFAULT NULL COMMENT ’工單類型’,demander varchar(30) DEFAULT NULL COMMENT ’需求方’,is_atomic char(1) DEFAULT ’y’ COMMENT ’是否原子工單’,atomic_id int(11) DEFAULT NULL COMMENT ’當前原子工單在列表中ID’, PRIMARY KEY (id)) ENGINE=InnoDB AUTO_INCREMENT=182431 DEFAULT CHARSET=utf8 COMMENT=’測試表’;

SHOW INDEX FROM test

ALTER TABLE test ADD INDEX test_title (title)EXPLAIN SELECT * FROM test.test WHERE id = 100 or title = ’gg’

EXPLAIN SELECT * FROM test.test WHERE title = ’ggg’

問題解答

一，數(shù)據(jù)量太少，制定執(zhí)行計劃時發(fā)現(xiàn)全表更快，可以往表里填幾百萬id和tittle不一樣的數(shù)據(jù)試試。二，確保mysql版本5.0以上，且查詢優(yōu)化器開啟了index_merge_union=on, 也就是變量optimizer_switch里存在index_merge_union且為on

補充一點：

@mokeyjay 的說法不是很正確，且過時?？梢钥纯匆韵挛臋n。

http://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html

老生常談了，直接引用一篇博文http://blog.csdn.net/hguisu/article/details/7106159

謝謝邀請。看看這篇文檔mysql關于or的索引問題 希望對你有幫助

贊成@xiayongsheng的說法， 在線上找了一含幾千萬數(shù)據(jù)的表， explain了一下or查詢

# id是主鍵， user_id是普通索引explain SELECT * from t WHERE id = 100000 or user_id = ’c7b6752c37b111e6a7d705b57e583e2e’;idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1SIMPLEtindex_mergePRIMARY,t_useridPRIMARY,t_userid4,123 2Using union(PRIMARY,t_userid); Using where