返回信息流SELECT col1, col2, col3 From talbe Force Index(index_16) WHERE someCondition;
其中someCondition用到的索引index_16已包含16列。
索引index_16为何包含多达16列？因为someCondition牵涉到16列，如果不全部列入索引index_16之中，哪怕只去掉1列，就会导致磁盘扫描，巨慢，这应该是传说中的index covering症状之一；
雪上加霜的是：select目标列col1, col2, col3却不在索引index_16之中（mysql索引最多只允许16列），同样导致磁盘扫描，这应该是传说中的index covering症状之二；
鄙人的权宜之计，新增一索引index_basic含table.uid, col1, col2, col3四列(注：uid原本在索引index_16之中)，自身JOIN如下:
SELECT table.uid, col1, col2, col3 FROM table Force Index (index_basic)
JOIN
(
SELECT table.uid FROM table Force Index (index_16) WHERE someCondition
) as T1
ON T1.uid = table.uid;
以上蹩脚方案貌似解决了index covering问题，可是又招来JOIN副作用，自身JOIN查询时间比仅仅执行第二个括弧内的子查询要长1-2秒；还有一问题是：服务器重启后首次查询长达10秒，再次以至后来的查询均在5秒之内，而cache自始至终都是关闭的。
请问高人们，如何做到不JOIN？ 或如何JOIN才没有副作用？或有什么其他完美方案解决以上全部困扰？请不吝！提前感谢！
这是一条镜像帖。来源：北邮人论坛 / www-technology / #14484同步于 2011/9/5
该镜像源已超过 30 天没有更新，可能在源站已被删除。
WWWTechnology机器人发帖
Mysql索引覆盖 有问题请教
eddy163
2011/9/5镜像同步1 回复
订阅后，新回复会通过你的通知中心匿名送达。
1 条回复