MSSQL中多表连接时驱动顺序对性能的影响
Tags： MSSQLSQL Server驱动表
👉 本文共约2986个字，系统预计阅读时间或需12分钟。
最近在SQL Server中多次遇到开发人员提交过来的有性能问题的SQL，其表面的原因是表之间去的驱动顺序造成的性能问题，
具体表现在（已排除其他因素影响的情况下），存储过程偶发性的执行时间超出预期，甚至在调试的时候，直接在存储过程的SQL语句中植入某些具体的参数，在性能上仍达不到预期的响应时间。
此类问题在排除了服务器资源因素，索引，锁，parameter sniff等常见问题之后，确认识是表之间的驱动顺序造成的，因为在尝试sql语句的末尾加上option(force order)之后，性能迅速提升。
通常情况下，表之间连接的时候是采用“小表驱动大表”是一种相对比较高效的方式，也即在loop join的时候，先循环小表，通过循环驱动大表，然后产生查询结果集。
该性能表面上看，是表之间的驱动顺序顺序造成的，在强制一个驱动顺序之后，性能有非常明显的提升，
但是再进一步思考，为什么默认情况下，SQL Server没有选择一个合理的驱动顺序？
因此本文就简单阐述这两个问题：
1）为什么表之间的驱动顺序会影响性能？
2）为什么SQL Server在某些情况下没有选择出正确的驱动顺序？
为什么表之间的驱动顺序会影响性能？
首先演示一下表在连接的时候，驱动顺序对性能的影响，其中test_smalltable插入1W行数据，test_bigtable插入10W行测试数据，依次来代表小表与大表
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | create table test_smalltable ( id int identity(1,1) primary key, otherColumns char(500) ) create table test_bigtable ( id int identity(1,1) primary key, otherColumns char(500) ) declare @i int = 0 while @i<100000 begin if @i<10000 begin insert into test_smalltable values (NEWID()) end insert into test_bigtable values (NEWID()) set @i = @i + 1 end |
在测试表写入数据完成之后，使用一下两个SQL，通过强制使用loop join的驱动顺序的方式来观察其IO情况
1 2 3 4 5 | select * from test_smalltable a inner loop join test_bigtable b on a.id = b.id option(force order) GO select * from test_bigtable a inner loop join test_smalltable b on a.id = b.id option(force order) GO |
如图，是两个SQL执行之后产生的IO信息，可以发现，因为两个表的驱动顺序不一致，导致的逻辑IO几乎差了一个数量级。
本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！
