小表驱动大表的基本概念
在数据库查询优化中，"小表驱动大表"是一种常见的性能优化策略。它的核心思想是：在进行多表关联查询时，优先选择数据量较小的表作为驱动表，去匹配数据量较大的表，从而减少整体的扫描次数和计算开销。
举个生活中的例子，假如你要在两个名单里找人：一个是公司全体员工名单（几千人），另一个是今天开会的参会人员名单（十几人）。如果你拿着长长的全员名单一个个去查谁来开会，效率显然很低。但反过来，拿那张短短的会议名单，逐个去大名单里查信息，就快得多。这就是“小表驱动大表”的实际体现。
为什么小表要当驱动表
数据库执行 JOIN 操作时，通常会用嵌套循环的方式处理。比如 LEFT JOIN，左表每一条记录都会去右表中查找匹配项。如果左表是大表，就要进行大量查找；而如果左表是小表，查找次数自然就少。
假设表 A 有 10 条数据，表 B 有 10000 条数据。如果用 A 驱动 B，最多进行 10 次对 B 的扫描或查找；但如果用 B 驱动 A，则可能需要扫描 A 上万次，效率差距明显。
结合索引效果更佳
小表驱动大表的效果还能被索引进一步放大。只要被驱动的大表在关联字段上有索引，每次从小表取出一条记录后，就能快速通过索引定位到大表的匹配行，避免全表扫描。
例如下面这个 SQL：
SELECT * FROM small_table s INNER JOIN large_table l ON s.id = l.user_id;只要 large_table 的 user_id 字段建了索引，数据库就可以高效地以 small_table 为驱动表，逐条匹配。
执行计划中的体现
在 MySQL 中，可以通过 EXPLAIN 查看执行计划。通常，驱动表会出现在执行计划的第一行（即 table 列的第一个表），也被称为“外层表”。优化器一般会自动选择小表作为驱动表，但前提是统计信息准确，并且索引设置合理。
不过有时候优化器判断失误，或者由于 SQL 写法问题导致大表被当作驱动表，这时性能就会明显下降。开发者可以通过调整 JOIN 顺序，或使用 STRAIGHT_JOIN 强制指定驱动关系来干预。
适用场景与注意事项
这种策略在 OLTP 场景中尤为有效，比如用户订单查询、权限校验等涉及主从表关联的操作。但在大数据量的 OLAP 场景中，JOIN 的实现方式可能更依赖于哈希或排序合并，不完全遵循这一规则。
需要注意的是，“小表”并不是单纯指物理大小，而是指参与关联的记录数。有时候一个表总数据很多，但通过 WHERE 条件过滤后结果很少，这时它依然可以作为驱动表。因此写 SQL 时，尽量先把过滤条件写清楚，让优化器能准确评估驱动顺序。