我有一个非常简单的MYSQL表，其中有2列，并运行以下查询：
SELECT * FROM table WHERE (col1 = '123' AND col2 = '456')
OR (col1 = '456' AND col2 = '123')
col1和col2是复合主键：PRIMARY KEY('col1','col2')。两者都也是另一个表中主键的外键
当我为上述查询运行EXPLAIN命令时，得到以下信息：
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE table index PRIMARY,col2 col2 8 NULL 1 Using where; Using index
在type上面的结果是index，这是非常相似All，因此很可能是一个大型数据库慢。有没有办法改善上述select命令
实际上，诸如的声明likely to be slow on a large database应该是一个危险信号。
如果您将要拥有一个大型数据集，则概要分析和测试对于首先确定是否会成为问题，然后确定是否足以解决开发时间和成本至关重要。通常，这意味着微优化不会对大多数代码库产生任何影响。
无论如何，让我们回答问题。
是的，假设使用索引文件是我们的假设，并且如果您有大量数据并查询此表，则有可能通过将查询拆分为多个执行集而不是在查询中使用表达式运算符来进行优化（如果您使用的是只查询两次，如您的示例所示，您可以通过以下方式获得更高的性能union：
(
SELECT * FROM test
WHERE
(
col1 = 123 AND col2 = 456
)
)
UNION
(
SELECT * FROM test
WHERE
(
col1 = 456 AND col2 = 123
)
)
在EXPLAIN此查询如下：
ID SELECT_TYPE TABLE TYPE POSSIBLE_KEYS KEY KEY_LEN REF ROWS EXTRA
1 PRIMARY test ref PRIMARY PRIMARY 4 const 1 Using where; Using index
2 UNION test ref PRIMARY PRIMARY 4 const 2 Using where; Using index
(null) UNION RESULT <union1,2> ALL (null) (null) (null) (null) (null)
看看这个SQL小提琴http://sqlfiddle.com/#!2/9dc07a/1/0，了解一个简单的测试用例。
我在这篇文章中使用的语言，例如“可能”，“可能”等，是因为我没有在此示例中预先加载数亿条记录-我强烈建议您这样做，并评估和分析您的查询更多详情。
不幸的是，通过优化，执行x以获得更好的性能并不总是一个简单明了的答案-查询优化器是一个复杂的野兽，有时试图获得每一个性能下降实际上都会削弱您的应用程序（我是从经验中讲）此处），除非您不必担心这些微观优化，否则，请在决定采用哪种方法之前不要进行评估，概要分析和测试。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句