mysql不走索引怎么解决的

上周 查我那个朋友的系统。
数据表太大。

没索引。

结果集超2 5 %。
全表扫描。
超慢。

算了。

oracle不走索引

Oracle不走索引主要原因和解决方法如下：
1 . 查询条件不匹配索引
索引失效：查询条件用非索引列或函数操作。
例子：WHERE TO_CHAR(date_column)='2 02 3 -01 -01 '会失效，因为对索引列做函数处理。

2 . 索引损坏或类型不匹配
数据类型或长度不匹配。
例子：索引建的是VARCHAR2 (1 0)，但查询用VARCHAR2 (2 0)，索引用不了。

索引被删除未重建。

3 . 统计信息过时
优化器选错执行计划。
例子：表数据量翻倍后，未更新统计信息，优化器仍选全表扫描。

---
解决方法
1 . 维护索引
检查状态，修复或重建损坏索引。
命令：ALTER INDEX index_name REBUILD。

2 . 更新统计信息
用DBMS_STATS收集最新数据。
例子：EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'TABLE');
3 . 优化查询语句
索引列避免函数操作。
例子：WHERE TO_CHAR(date_column)='2 02 3 -01 -01 '改为WHERE date_column=TO_DATE('2 02 3 -01 -01 ', 'YYYY-MM-DD')。

确保类型长度一致。

4 . 增加合适索引
根据查询创建联合索引。
例子：高频查询的多个字段建组合索引，但注意写入影响。

你自己掂量。

什么情况下数据库索引会失效?

说实话，数据库索引这玩意儿挺有意思的，但用不好就容易成摆设。
我当年刚入行那会儿，写个查询跑半天，老板催得紧，最后发现是索引没用对——血亏。

就拿where子句里判断null值来说吧。
比如我之前搞过一个电商系统，表里有个用户等级字段level，当时加了索引。
结果写了个查询SELECT FROM users WHERE level IS NULL，你猜怎么着？数据库直接把索引当废纸扔了，全表扫了一遍。
我当场就蒙了，跑去问导师，导师说："这玩意儿是NULL特殊处理，索引树里根本存不了NULL，数据库觉得你肯定得查全表。
"后来改写成了SELECT FROM users WHERE level = 0 OR level IS NULL，索引才又捡了回来。

不等于操作符（!=）那块我也踩坑过。
有次做报表需求，写了个SELECT FROM orders WHERE amount != 0，金额字段(amount)明明有索引，结果还是慢得要死。
查资料才知道，大部分数据库对不等于操作符特别不感冒，觉得你肯定得全表扫。
后来改成SELECT FROM orders WHERE amount > 0，性能立马起飞。
这教训我记到现在，写查询时看见!=就浑身起鸡皮疙瘩。

or连接条件更魔幻。
我接手过一个老项目，有个查询SELECT FROM logs WHERE ip = '1 9 2 .1 6 8 .1 .1 ' OR user_id > 1 0000，ip字段有索引，但user_id没有。
结果数据库压根不用ip的索引，直接全表扫。
这特么就像你拿着火柴找打火机，非要翻整个沙发——数据库引擎也这么干。
后来改写成两个独立查询再union，性能好了不是一点半点。

in操作符那块也挺坑人。
有次写个查询SELECT FROM products WHERE id IN (1 ,2 ,3 ,...,1 0000)，明明id字段是索引，但数据量一大（比如超过5 000个数字），数据库就放弃索引了。
我当时还纳闷，难道数据库有选择困难症？后来查了官方文档才知道，这跟数据库内存和配置有关。
但有个例外，in里就一个值时，索引肯定能用，这点倒是挺靠谱。

函数操作更离谱。
有次写个查询SELECT FROM users WHERE YEAR(reg_date) = 2 02 0，注册日期(reg_date)明明有索引，结果还是全表扫。
我当时直接傻了，心想这数据库是不是抽风了？后来改写成SELECT FROM users WHERE reg_date BETWEEN '2 02 0-01 -01 ' AND '2 02 0-1 2 -3 1 '，索引立马复活。
这就像你非要拿着放大镜找一根针，非得把整个桌子上的灰尘都扫掉——数据库也这么干。

like查询那块我也踩过坑。
有次写个查询SELECT FROM articles WHERE title LIKE '%search%'，结果发现索引完全没起作用。
这我还挺纳闷，明明匹配模式不是以%开头的啊。
后来导师一指点，说like以%开头时，索引树根本没法用，只能全表扫。
但title LIKE 'search%'是能用索引的，这点倒是挺有意思。

联合索引的最左前缀原则更得死记硬背。
我接手过一个项目，有个联合索引(a,b,c)，写了个查询SELECT FROM orders WHERE b = 'summer'，结果发现索引完全没用。
当时我直接懵了，心想这数据库是不是疯了？后来导师说："联合索引就像一排锁，a是挂锁，b是插销，c是挂链，你只拔插销，锁肯定打不开啊。
"这比喻太形象了，我现在写查询前都会先看联合索引的最左前缀。

说实话，数据库索引这玩意儿挺反直觉的，得反复踩坑才能明白。
但一旦掌握了门道，性能提升那可不是盖的。
我现在的习惯是写完查询先问自己："这索引用对了吗？"——虽然有时候还是会被坑，但至少没那么频繁了。