sql复杂查询语法的mysql性能如何优化

in 语句实际上对索引不是特别友好。
想一想，In语句需要把所有的值都拉出来然后进行匹配，所以索引就没啥用了。
上次调试SQL时，表中有数百万条数据，In语句卡住了。
后来我改用子查询，分成两步。
首先我查了表1 和表2 ，然后根据结果查了表3 速度顿时更快了。
例如，表 1 包含 1 00 万个条目，表 2 包含 5 00,000 个条目。
如果直接进去的话，就得全部扫描。
但先用表1 和表2 得到初步结果，然后再到表3 进行匹配，使索引发挥良好作用。
我测试过，更改十多秒后，查询时间减少到一到两秒。
因此，对ID建立索引非常重要，使用时需要注意策略。

查询效率提升10倍！3种优化方案，帮你解决MySQL深分页问题

子问题： 按ID过滤；使用有效标签。
回表操作性能提升3 倍。
适合高要求的深度分页情况。

内饰： 子查询临时表是相对于原表的。
性能是相对的，功能是复杂的。
适合高要求、复杂情况。

分页光标： 相关条件；映射光标。
生效时间几乎是0秒。
不支持快速跳转。
适合少量数据的连续分页。

根据请求状态选择一个程序。

MySQL性能调优

架构层面的优化： 主从分离：从主库写入，从库读取，分担压力。
集群模式：MySQLCluster/GaleraCluster，多节点，高可用，负载均衡。
分库分表：水平或垂直拆分百万表，减少单表压力。

SQL优化策略： 分析执行计划：EXPLAIN，查看类型、键、行等。
索引使用原则：最左边前缀，索引a,b,c支持a,a,b,a,b,c查询。
避免函数操作：WHEREYEAR(date_column)=2 02 3 会导致索引错误。
避免全表扫描：确保查询可以建立索引。
type=ALL 不起作用。

分页查询优化： 百万数据：不要使用LIMITM，N，使用主键索引分页。
方法一：SELECTFROMtable_nameWHEREid>(pageNum1 0)LIMIT1 0; 方法二：SELECTFROMtable_nameWHEREid>(pageNum1 0)ORDERBYidASCLIMIT1 0; 方法三：子查询分页。

查询条件优化： 避免使用 != 或 <>：不能使用索引。
使用 IN 或 UNIONALL 代替： 推荐：SELECTFROMtable_nameWHEREa=1 UNIONALLSELECTFROMtable_nameWHEREb=2 ANDa!=1 避免 NULL 计算：将其替换为默认值。

表结构优化： 字段类型选择：数字类型比字符串类型更高效，VARCHAR替代CHAR。
字段设计原则：避免NULL、设置默认值、拆分TEXT/BLOB。
不要存储大文件：使用图像的文件系统路径。

索引优化： 索引创建原则：查询条件、ORDERBY索引创建、组合索引优先级。
字符字段前缀：KEY(name(1 0))。
使用索引的禁忌：不允许对列进行函数操作，因此避免过多的索引。

数据库规格： 核心规范：计算逻辑下移至应用层，控制单表数据量。
字段规范：TINYINT替代INT，ENUM/SET存储固定值并自动递增主键。
SQL规范：简单语句、短事务、无存储过程、COUNT(1 )而不是COUNT()。
约定规范：隔离环境，utf8 mb4 字符集，凌晨更新。

性能监控和优化： 慢查询日志：SQL解析超时。
监控工具：SHOWSTATUS、SHOWPROCESSLIST。
定期维护：可分析/可优化。

说实话：多尝试看看效果。