我对复合主键和列的基数有一些疑问。我在网上搜索，但没有找到任何确定的答案，所以我再试一次。问题是：
上下文：大型（50M - 500M行）OLAP Prep表，而不是NOSQL，不是Columnar。 MySQL和DB2
1）PK中键的顺序是否重要？
2）如果列的基数变化很大，应首先使用。例如，如果我有CLIENT / CAMPAIGN / PROGRAM，其中CLIENT是高度基数，CAMPAIGN是适中的，PROGRAM几乎就像一个位图索引，什么顺序是最好的？
3）如果有Where子句且没有Where子句（对于视图），哪种顺序最适合加入
提前致谢。
答案 0 :(得分：3)
你有“MySQL 和 DB2”。这个答案适用于DB2，MySQL没有这个。
是的，当然这是合乎逻辑的，但优化者需要的不仅仅是考虑到这一点。
通常，WHERE子句（join）中列的顺序不会（也不应该）重要。
但是，有两个与谓词顺序相关的项目可能是您提问的原因。
重要的是索引中列的顺序，WHERE子句与之对应。是的，最好按最高基数到最低的顺序指定列。这允许优化器定位较小的行范围。
正在加入的表（不是联接中的列）的顺序非常重要，这可能是最重要的考虑因素。事实上，Join Transitive Closure是自动的，优化器会根据统计信息评估所有可能的连接顺序，并选择它认为最好的连接顺序（这就是UPDATE STATS非常重要的原因）。
无论表中没有行，如果你在一个好的索引上的table_B中的一个坏索引上加入100行from table_A，你需要订单A：B，而不是B：A。如果你的得分低于最大IOPS，你可能想要做些什么。
正确的步骤顺序是毫不奇怪的：
按照（1）检查索引是否正确。不要只是添加另一个索引，更正你拥有的索引。
检查更新统计信息是否定期执行
始终首先尝试优化器的默认操作。设置统计数据并测量I / O.使用代表性的值集（用户将在生产中使用）。
检查shoowplan，确保代码正确无误。当然，这也将标识所选择的连接顺序。
如果性能不够好，并且您认为优化器为那些集值选择的连接顺序是次优的，则SET JTC OFF（语法取决于您的DB2版本），然后在WHERE子句中指定所需的顺序。测量I / O.使用代表集
形成意见。选择总体上更好的表现。永远不要调整单个查询。
答案 1 :(得分：2)
1）PK中键的顺序是否重要？
是的，它会更改用于监管PRIMARY KEY的索引的记录顺序。
2）如果列的基数变化很大，应首先使用。例如，如果我有CLIENT / CAMPAIGN / PROGRAM，其中CLIENT是高度基数，CAMPAIGN是适中的，PROGRAM几乎就像一个位图索引，什么顺序是最好的？
对于选择查询，这完全取决于您要使用的查询。如果您一次搜索所有三列，则顺序并不重要;如果您要搜索两列或一列，它们应该在索引中占据领先地位。
对于插入，最好使前导列与插入记录的顺序相匹配。
3）如果有Where子句且没有Where子句（对于视图），哪种顺序最适合加入
同样，这取决于WHERE子句。