假设有一张 software 表,表结构如下
software_id (int) | author_id (int) | create_time | update_time |
---|---|---|---|
1 | 1 | 2024-11-05 11:00:00 | 2024-11-05 11:00:00 |
2 | 2 | 2024-11-05 11:00:00 | 2024-11-05 11:00:00 |
其中 software_id 是主键,author_id 是普通索引
还有一张 company_software 表,表结构如下
company_software_id (int) | author_id (int) | country(varchar) | software_id (varchar) |
---|---|---|---|
1 | 1 | china | 1 |
2 | 1 | china | kkk |
其中 company_software_id 是主键,author_id 、country 、software_id 是一个复合索引。
以上表数据量只有 1~5w 。
1 、SQL1
SELECT 1
FROM company_software AS company_software
WHERE company_software.author_id = 1
and company_software.country in ('china', 'korea', 'england')
and company_software.software_id = '1'
并不会导致慢查询
2 、SQL2
SELECT software_id
FROM sortware
WHERE author_id = 1
and NOT EXISTS (SELECT 1
FROM company_software AS company_software
WHERE company_software.author_id = 1
and company_software.country in ('china', 'korea', 'england')
and CONVERT(sortware.software_id , char) = company_software.software_id)
LIMIT 0, 100
为什么会导致慢查询,懂的大佬帮忙分析下
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.