南通住房和城乡建设部网站首页做网站 备案

南通住房和城乡建设部网站首页,做网站 备案,广州工商注册大厅,襄城县住房和城乡建设局网站一、查询语句本身的优化#xff08;最易落地#xff09;这是优化查询速度的第一道关卡#xff0c;很多慢查询问题根源就在 SQL 写法上#xff1a;1. 精简查询字段#xff0c;避免SELECT *做法#xff1a;只查询业务需要的字段#xff0c;而非全字段。原因#xff1a;减…一、查询语句本身的优化最易落地这是优化查询速度的第一道关卡很多慢查询问题根源就在 SQL 写法上1. 精简查询字段避免SELECT *做法只查询业务需要的字段而非全字段。原因减少网络传输数据量、避免回表若索引能覆盖所需字段可直接走索引查询、降低内存消耗。sql-- 差的写法 SELECT * FROM user WHERE id 100; -- 优的写法 SELECT id, name, phone FROM user WHERE id 100;2. 避免在 WHERE 子句中操作字段导致索引失效做法不要对 WHERE 后的字段做函数 / 运算处理提前计算好条件值。原因MySQL 无法使用索引会触发全表扫描。sql-- 差的写法函数操作字段 SELECT * FROM order WHERE DATE(create_time) 2025-12-24; -- 优的写法条件值预处理 SELECT * FROM order WHERE create_time BETWEEN 2025-12-24 00:00:00 AND 2025-12-24 23:59:59;3. 优化子查询优先用 JOIN 替代做法相关子查询依赖外部查询的子查询效率极低改用 JOIN 关联。原因子查询会多次执行外部查询每一行都执行一次子查询JOIN 只需一次关联计算。sql-- 差的写法子查询 SELECT * FROM user WHERE id IN (SELECT user_id FROM order WHERE amount 1000); -- 优的写法JOIN SELECT DISTINCT u.* FROM user u JOIN order o ON u.id o.user_id WHERE o.amount 1000;4. 避免ORDER BY RAND()和无限制的排序做法ORDER BY RAND()会全表扫描 随机排序效率极差排序时确保排序字段有索引且只排序必要数据。替代方案若需随机取数可先查主键再随机筛选减少排序数据量。sql-- 差的写法全表随机 SELECT * FROM product ORDER BY RAND() LIMIT 10; -- 优的写法先查主键范围再随机 SELECT * FROM product WHERE id BETWEEN 1 AND 10000 ORDER BY RAND() LIMIT 10;5. 合理使用 LIMIT避免全量返回做法分页查询或只取部分数据时必须加LIMIT且结合WHERE缩小范围。原因避免一次性返回几十万 / 百万条数据占用内存和网络带宽。二、表结构设计优化从源头减少查询开销适合表设计阶段或重构阶段1. 选择最优数据类型核心原则够用即可越小的类型查询越快占用磁盘 / 内存更少索引更高效。用INT/BIGINT存 ID而非VARCHAR用DATETIME/TIMESTAMP存时间而非VARCHAR枚举值用ENUM而非VARCHAR如性别ENUM(男,女)。2. 分表优化应对大表当单表数据量超过 1000 万行时即使加索引也会变慢需分表水平分表按行拆分如订单表按创建时间拆分为order_202501、order_202502垂直分表按列拆分如用户表拆分为user_base基础信息和user_extra扩展信息减少单表字段数。3. 避免 NULL 值尽量做法给字段设置默认值如字符串默认 数字默认 0而非允许NULL。原因NULL会增加索引和查询的开销MySQL 需特殊处理 NULL 值且聚合函数如COUNT()会忽略 NULL 值易出错。三、数据库配置优化调整 MySQL 的核心配置参数充分利用服务器资源1. 优化 InnoDB 缓存核心innodb_buffer_pool_sizeInnoDB 的缓存池用于缓存数据和索引建议设置为物理内存的 50-70%如服务器 16G 内存设为 10G。作用让常用数据 / 索引常驻内存避免频繁读磁盘磁盘 IO 是查询慢的主要瓶颈。2. 调整排序 / 连接缓存sort_buffer_size排序缓存用于ORDER BY/GROUP BY按需调整不要过大避免内存竞争join_buffer_sizeJOIN 关联缓存优化多表连接的效率。3. 关闭无用的查询缓存MySQL 8.0 已移除MySQL 5.7 及以下的query_cache_size查询缓存会缓存 SQL 语句和结果但更新频繁的表会导致缓存频繁失效反而拖慢速度建议关闭设为 0。四、架构 / 硬件层面优化适合中大型系统的进阶优化1. 读写分离部署主从架构主库负责写操作INSERT/UPDATE/DELETE从库负责读操作SELECT分摊查询压力。原理从库通过主库的 binlog 同步数据所有查询请求路由到从库降低主库负载。2. 使用缓存Redis/Memcached缓存热点查询结果如首页推荐数据、用户基础信息避免频繁查询数据库。示例查询用户信息时先查 Redis若没有再查 MySQL查到后同步到 Redis。3. 升级硬件磁盘用 SSD 替代机械硬盘IO 速度提升 10 倍以上内存增加服务器内存让更多数据缓存到内存CPU升级多核 CPU提升并发查询处理能力。五、辅助优化手段1. 用 EXPLAIN 分析执行计划优化前先定位瓶颈在查询语句前加EXPLAIN查看 MySQL 的执行计划是否走索引、扫描行数、连接方式等。sqlEXPLAIN SELECT id, name FROM user WHERE phone 13800138000;重点看type列ALL 全表扫描ref/range/eq_ref 走索引越优看rows列预估扫描行数行数越少越好。2. 定期分析表更新统计信息sqlANALYZE TABLE user;作用更新表的统计信息如数据分布、行数让 MySQL 优化器生成更优的执行计划。3. 优化覆盖索引创建包含查询所需所有字段的索引无需回表查询速度比普通索引更快sql-- 查询字段id主键、name、phone -- 创建覆盖索引 CREATE INDEX idx_name_phone ON user(name, phone);总结MySQL 查询优化是多维度的除了索引还需优化查询语句、表结构、配置参数甚至架构 / 硬件核心思路减少数据扫描量如精简字段、用 WHERE 缩小范围、利用缓存内存 / Redis、降低磁盘 IO 和资源竞争优化前先通过EXPLAIN分析执行计划定位瓶颈后再针对性优化避免盲目加索引 / 改配置。