存储过程本身不决定是否全表扫描，真正起作用的是它内部SQL语句的执行路径；应先用EXPLAIN带实际参数验证执行计划，重点检查key是否为空、type是否为ALL、Extra是否含Using where但无Using index，再针对性优化索引设计、避免隐式转换、函数处理、参数嗅探及回表等问题。
存储过程里WHERE条件没走索引，怎么办
存储过程本身不决定是否全表扫描，真正起作用的是它内部的SQL语句执行路径。最常见的情况是：明明表上有索引，但存储过程一跑就type=ALL。先别急着改存储过程，直接在MySQL里用EXPLAIN跑一遍里面的SELECT语句——注意要带实际参数值，比如EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid'。
重点检查三点：key字段是否为空、type是否为ALL、Extra里有没有Using where但没Using index。如果user_id和status是分开建的单列索引，优化器大概率只选一个，另一个条件就得扫；这时应该建复合索引(user_id, status)，且顺序不能反——因为存储过程中通常是先传@user_id再过滤status。
- 别信“索引存在就一定生效”，用
SHOW INDEX FROM orders确认索引真实存在且没被禁用 - 存储过程参数传入后，如果做了隐式转换（比如
@mobile是INT类型，但字段是VARCHAR），索引立刻失效 - 避免在WHERE里写
IS NULL或!=，哪怕字段有索引，优化器也倾向全表扫描；改成=或IN列表更稳
存储过程调用时参数嗅探导致索引失效
MySQL虽不像SQL Server那样有显式的“参数嗅探”机制，但在存储过程中，如果使用变量参与WHERE条件（如WHERE create_time > @start_time），而该变量值在不同调用间差异极大（比如一次查1天数据，一次查1年），优化器可能基于第一次编译时的统计信息生成次优计划，并缓存下来——后续调用即使数据范围小，仍按大范围计划执行，结果就是本该走索引却扫了全表。
临时解法是加SQL_NO_CACHE或强制重编译：SELECT ... FROM orders WHERE create_time > @start_time FORCE INDEX (idx_create_time)。但更可持续的做法是：把时间范围拆成两个确定常量，比如WHERE create_time BETWEEN @start_time AND @end_time，并确保idx_create_time是单列索引或复合索引的最左列。
- 不要在存储过程里对参数做函数处理，比如
WHERE DATE(@dt) = CURDATE()，应提前算好@start和@end - 如果必须动态拼接条件，优先用
IF分支分别写多个明确SELECT，而不是用OR或CASE WHEN混在一个WHERE里 - 定期运行
ANALYZE TABLE orders，尤其在大批量导入或删除后，否则优化器会按过时的行数估算选择全表扫描
存储过程返回大量中间结果引发隐式全表扫描
很多存储过程习惯先查一堆数据到临时表或游标里，再逐行处理——比如CREATE TEMPORARY TABLE tmp_orders SELECT * FROM orders WHERE status = 'pending'。这句本身可能走了索引，但一旦SELECT *涉及TEXT/BLOB字段，或者没覆盖索引，就会触发回表+全行读取，IO压力陡增；更糟的是，后续对tmp_orders的操作（如JOIN、GROUP BY）根本没索引，只能全表扫。
关键不是“能不能用临时表”，而是“要不要全字段+全数据”。能精简就精简：SELECT id, user_id, amount INTO tmp_ids FROM orders WHERE status = 'pending' AND create_time > DATE_SUB(NOW(), INTERVAL 7 DAY)，只拿必要ID，再用这些ID去主表精准关联。
- 临时表字段尽量定义NOT NULL，避免后续查询因NULL判断绕过索引
- 如果临时表数据量预估超1万行，考虑用普通表+唯一前缀命名+定时清理，而不是
TEMPORARY——后者无法建索引 - 游标循环里嵌套查询（如
SELECT ... FROM detail WHERE order_id = cur_order_id）极易放大问题，改成一次性JOIN更高效
存储过程里ORDER BY / GROUP BY触发文件排序，间接导致扫描加剧
即使WHERE走了索引，如果ORDER BY create_time字段不在索引里，或顺序不匹配（比如索引是(user_id, create_time)，但ORDER BY是create_time DESC），MySQL会先按WHERE拿到所有ID，再回表取出全部行，最后在内存或磁盘排序——这个Using filesort过程本身不等于全表扫描，但它让原本只需读索引页的查询，变成要读完整数据页，IO翻倍，看起来像“扫得更慢了”。
解决方法很直接：把排序字段塞进索引末尾。比如常用WHERE user_id = ? ORDER BY create_time DESC，那就建INDEX idx_user_time (user_id, create_time)。注意DESC在MySQL 8.0+才真正支持索引排序，之前版本一律当ASC处理，所以旧环境要避免写DESC。
- GROUP BY同理，优先让分组字段成为索引最左列，避免
Using temporary - 如果排序字段是表达式（如
ORDER BY YEAR(create_time)），索引完全无效，必须提前计算好年份字段并单独建索引 - 存储过程里用
LIMIT时，确保它在ORDER BY之后——否则优化器可能放弃索引排序，直接扫完再截断
实际中真正卡住的，往往不是“没建索引”，而是索引建了但存储过程里的变量、函数、拼接逻辑悄悄绕过了它。每次修改后，务必用真实参数跑EXPLAIN，别依赖开发环境的小数据集表现。
