The CBO will evaluate n! different join orders for a particular query where n
is the number of tables in the query.实际上Optimizer 会避免重复的工作，同时对那些明显cost 已经大于现在已经获得
的execute plan 不会continue down parth.同时仍然存在很多cutoffs（捷径）以确保optimizer 不会花费过长的时间来决定
一个执行计划。最常见的一个cutoff 就是80000 permutations（置换），即Optimizer 只会尝试80000种匹配，当查询语句中
涉及到的表很多时，效果很明显，但同时也带来负面效应就是可能获得执行计划不是最佳的(sub-optimal plan)
Number of tables Total number Proportion of
of possible total represented
permutations by 80,000 permutations
(n) (n!) ( 80,000 / n! * 100)
1 1 Not Relevant
2 2 Not Relevant
3 6 Not Relevant
4 24 Not Relevant
5 120 Not Relevant
6 720 Not Relevant
7 5040 Not Relevant
8 40320 Not Relevant
9 362880 22%
10 3628800 2.2%
11 39916800 0.2%
12 479001600 0.016%
13 6226020800 0.001284%
14 87178291200 0.000092%
15 1307674368000 0.000006%
从这组数据中可以看出，9张表以上的情况，都只会尝试80000次匹配，但要注意表的数量多的情况，单次Plan 评估的时间与表少
的情况相比要长一些。
针对涉及到10张以上表的情况，很有可能获得的不是最佳的执行计划。
为了避免这种情况:
1, 可以使用hint 人为选择最佳执行计划
2, 可以修改参数OPTIMIZER_MAX_PERMUTATIONS
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/158700/viewspace-758033/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
没有了~
请登录后发表评论
登录
全部评论
