表扫描发生在查询无法利用索引时，逐行读取数据影响性能；2. 优化核心是减少数据读取、提升效率；3. 合理创建索引可避免全表扫描；4. 为WHERE、JOIN等子句中的高频字段建索引；5. 复合索引需匹配查询条件顺序；6. 避免过度索引以减少写开销；7. 使用EXPLAIN检查执行计划；8. 优化SQL结构防止索引失效；9. 避免在WHERE中对字段进行函数操作。
在MySQL中，表扫描（Table Scan）是指数据库引擎逐行读取整张表的数据来查找符合条件的记录。当查询无法有效利用索引时，就会发生全表扫描，这在大数据量场景下会显著影响性能。优化表扫描的核心在于减少不必要的数据读取、提升查询效率。以下是几个实用的优化技巧。
合理创建和使用索引
索引是避免全表扫描最有效的手段。为经常出现在WHERE、JOIN、ORDER BY和GROUP BY子句中的列建立合适的索引，可以大幅减少需要扫描的行数。
- 对高频查询字段建立单列或复合索引，注意复合索引的列顺序应与查询条件匹配
- 避免过度索引，因为索引会增加写操作的开销并占用存储空间
- 使用EXPLAIN命令查看执行计划，确认查询是否命中索引
优化查询语句结构
即使有索引，不合理的SQL写法也可能导致索引失效，从而触发表扫描。
- 避免在WHERE条件中对字段进行函数操作或表达式计算，如WHERE YEAR(create_time) = 2023，应改为范围查询
- 尽量不用LIKE '%value%'这类前后模糊匹配，它通常无法使用索引
控制数据访问范围
通过限制查询的数据范围，可以显著降低扫描的数据量。
- 在时间范围、状态等维度上做分区（Partitioning），例如按月分区，使查询只需扫描特定分区
- 在应用层做好分页，避免一次性拉取大量数据，使用LIMIT和OFFSET（注意深分页问题）
- 尽早过滤数据，把高筛选性的条件放在前面
定期维护表和统计信息
MySQL的查询优化器依赖表的统计信息来决定执行计划。过时或不准确的统计可能导致错误选择全表扫描。
- 执行ANALYZE TABLE更新表的索引统计信息
- 对频繁增删改的表定期优化，可使用OPTIMIZE TABLE（适用于MyISAM）或重建表（InnoDB）
- 监控表的碎片情况，碎片过多会影响扫描效率
基本上就这些。关键是在设计阶段考虑查询模式，合理建模和建索引，运行中持续监控慢查询日志，及时调整。表扫描不是完全要避免，但在大多数OLTP场景中应尽量减少其发生。
