真正限制扫描行数靠索引覆盖与FORCE INDEX，而非LIMIT或SQL_CALC_FOUND_ROWS；优化器是否走索引、统计信息准确性及查询写法才是关键，超时参数和优化器调优仅作兜底。
用 SQL_CALC_FOUND_ROWS + LIMIT 不能真正限制扫描行数
很多人以为加了 LIMIT 10 就只扫 10 行，其实不然。MySQL 仍会先找到所有匹配行（比如 10 万行），再截取前 10 条返回——SQL_CALC_FOUND_ROWS 更是加重这一步开销。
真正起作用的是优化器是否能利用索引快速定位并提前终止扫描。如果 WHERE 条件没走索引，或用了 LIKE '%abc'、OR 连接多个非索引字段，LIMIT 基本无效。
- 检查执行计划：必须看
EXPLAIN输出里的rows字段，不是看结果集大小 - 避免在大表上对无索引字段做
ORDER BY+LIMIT，排序本身就要读全量数据 -
LIMIT对SELECT COUNT(*)完全无效，这类聚合必然全表/全索引扫描
设置 max_execution_time 是最直接的超时兜底手段
MySQL 5.7.8+ 支持语句级超时，单位毫秒，触发后直接中断查询，避免慢查拖垮连接池或锁住资源。
它不依赖 SQL 写法，也不管有没有索引，只要执行时间超限就 kill，适合防雪崩场景。
- 会话级设置：
SET SESSION max_execution_time = 2000（2 秒） - 全局默认值可写进配置文件：
max_execution_time = 1000 - 仅对
SELECT生效，INSERT ... SELECT中的SELECT部分也受控 - 注意：超时错误码是
Query execution was interrupted, maximum statement execution time exceeded，应用层要识别并处理
optimizer_search_depth 和 range_optimizer_max_mem_size 影响优化器决策成本
优化器在生成执行计划前，要评估多种索引组合和访问路径。当表字段多、索引多、条件复杂时，这个过程本身可能卡住，尤其在低配机器上。
这两个参数不控制扫描行数，但控制“优化器自己花多少力气找最优计划”。设得太小，可能选错索引；设得太大，优化阶段就超时或吃光内存。
-
optimizer_search_depth = 6（默认为 64）可显著缩短复杂查询的准备时间，适合 OLTP 场景 -
range_optimizer_max_mem_size = 8388608（默认 8MB）限制范围扫描的内存估算上限，设为 0 表示不限制，但可能导致优化器误判 - 修改后需观察
Slow_queries和Handler_read_*状态变量变化，确认没因跳过路径评估而退化到全表扫描
真正限制物理扫描行数，靠的是索引覆盖 + FORCE INDEX
没有索引，一切资源限制都是补救；有索引，才能让 LIMIT 发挥实际效果。关键不是“能不能加限制”，而是“MySQL 愿不愿意只扫几行就停”。
当优化器因统计信息陈旧或代价模型偏差选错索引时，FORCE INDEX 能强制走指定索引，把扫描范围压到最小。
- 例如：
SELECT * FROM orders FORCE INDEX (idx_user_status) WHERE user_id = 123 AND status = 'paid' LIMIT 1 - 配合
Covering Index（所有SELECT字段都在索引中），可避免回表，进一步减少 I/O 行数 - 别迷信
FORCE INDEX—— 如果索引本身区分度差（比如status只有 3 个值），照样要扫大量索引项
扫描行数这事，永远卡在索引设计和查询写法上。超时参数和优化器调优只是保底，不是替代方案。
