MySQL性能优化---优化方案

1.对查询进行优化,应尽量避免全表查询,首先考虑在where及order by涉及的列上建立索引;

2.应尽量避免where子句中对字段进行null值判断,否则将导致引擎放弃使用索引而进行全表扫描;

  

   创建一个普通索引:

#普通索引
CREATE INDEX accountname ON accounts(accountname)

  

  查询null值:

EXPLAIN SELECT * FROM accounts WHERE accountname=NULL

  

##尽量使用IS NULL的方式来查询空值
EXPLAIN SELECT * FROM accounts WHERE accountname IS NULL  

3.应尽量避免在where子句中使用!=或者<>操作符,否则将引擎放弃使用索引而进行全表扫描;

4.应尽量避免在where子句中使用or来连接条件,否则将导致引擎放弃使用索引而进行全表扫描;

EXPLAIN SELECT * FROM accounts WHERE accountname=‘小强‘ OR accountname=‘小红‘ 

  

EXPLAIN SELECT * FROM accounts WHERE accountname=‘小强‘
    UNION ALL
        SELECT * FROM accounts WHERE accountname=‘小红‘

  

5.in和not in也要慎用,否则会导致全表扫描;

select id from t where num in(1,2,3)
##对于连续的数值,能用 between 就不要用 in 了
select id from t where num between 1 and 3

6.下面的查询也将导致全表扫描;

select id from t where name like ‘%abc%‘ 

7.应尽量避免在where子句中对字段表达式操作,这将导致引擎放弃使用索引而进行全表扫描;

select id from t where num/2=100    

##应为:    

select id from t where num=100*2 

8.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描;

##name以abc开头的id
select id from t where substring(name,1,3)=‘abc‘  

##应为:    

select id from t where name like ‘abc%‘ 

9.不要在where子句中“=”左边进行函数,算术运算或其他表达式运算,否则系统将可能无法正确使用索引;

10.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽量的让字段顺序与索引顺序一致;

11.不要写一些没有意义的查询,如需要生成一个空结构;

select col1,col2 into #t from t where 1=0
##这类代码不会返回任何结果集,但是会消耗系统资源的,应改为这样:
create table #t(...)  

12.很多时候exist是代替in是一个很好的选择;

select num from a where num in(select num from b)
##用下面的语句替换:
select num from a where exists(select 1 from b where num=a.num)  

13.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引;

14.索引并不是越多越好,索引固然可以提高相应的select的效率,但同时也降低了insert和delete的效率;因为insert好额delete有可能会重建索引,所以怎样键索引需要慎重考虑;一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要;

15.尽量使用数字字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销;这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了;

16.尽可能的使用varchar代替char,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些;

17.任何地方都不要使用select * from 表名 ,用具体的字段代替“*”,不要查询用不到的字段;

18.避免频繁创建个删除临时表,以减少系统表资源的消耗;

19.临时表并不是不可使用,适当地使用它们可以使某些例程更有效;

20.在新建临时表时,如果一次性插入数据数据量很大,那么可以使用select into代替create table,避免造成大量log,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table ,然后insert into;

21.如果使用了临时表,在存储过程的最后务必将所有的临时表显示删除,先truncate table,然后drop table,这样可以避免系统表较长时间锁定;

22.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写;

23.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效;

24.与临时表一样,游标并不是不可使用。对小型数据集使用FAST_FORWARD游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时,在结果集中包含“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看看哪种效果好;

25.尽量避免大事务操作,提高系统并发能力;

26.尽量避免向客户端返回大数据量,若数据量过大,应该考虑响应需求是否合理;

原文地址:https://www.cnblogs.com/Zzzzn/p/12336132.html

时间: 2024-10-29 13:44:45

MySQL性能优化---优化方案的相关文章

mysql性能及优化探讨

最近在公司内部进行了一次mysql性能和优化相关的内部分享,放在这里备忘,同时也希望能跟大家交流相关的话题,整理自书本及网络上的文章,感谢相关内容的作者 在百度文库上有,可以点击这里

Mysql性能的优化配置

一.MySQL 性能优化之-影响性能的因素 1. 商业需求的影响 不合理需求造成资源投入产出比过低,这里我们就用一个看上去很简单的功能来分析一下. 需求:一个论坛帖子总量的统计,附加要求:实时更新 从功能上来看非常容易实现,执行一条 SELECT COUNT(*) from 表名 的 Query 就可以得到结果.但是,如果我们采用不是 MyISAM 存储引擎,而是使用的 Innodb 的存储引擎,那么大家可以试想一下,如果存放帖子的表中已经有上千万的帖子的时候,执行这条 Query 语句需要多少

mysql 性能配置优化

修改mysql配置文件 my.cnf ,内容如下: [mysqld]datadir=/data/mysql/datasocket=/var/lib/mysql/mysql.sockuser=mysql# Disabling symbolic-links is recommended to prevent assorted security riskssymbolic-links=0# 设置默认字符集,避免无法输入中文character_set_server=utf8init_connect='S

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

redmine在linux上的mysql性能优化方法与问题排查方案

iredmine的linux服务器mysql性能优化方法与问题排查方案 问题定位: 客户端工具: 1. 浏览器inspect-tool的network timing工具分析 2. 浏览器查看 response header, 分析http server 与 web server.       服务器工具:   0. nmon 查看各类系统负载, rrdtool 查看网络状况.   1. uptime看cpu负载;    free看内存;  mem ; cat /proc/meminfo以及  i

mysql 性能优化方案

这是一篇关于mysql 性能优化的文章.网上有不少mysql 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用status信息对mysql进行具体的优化. mysql> show global status; 可以列出MySQL服务器运行各种状态值,另外,查询MySQL服务器配置信息语句:mysql> sho

详解MySQL大表优化方案

当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT.SMALLINT.MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的

针对MySQL大表优化方案

详解MySQL大表优化方案 (1).字段 (2).索引 (3).规范查询SQL (4).存储引擎 (5).mysql配置参数优化 (6).mysql读写分离 (7).分区和分表 单表优化: 当单表的数据不是一直在暴增,不建议使用拆分,拆分会带来逻辑,部署,运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量 (1).字段 l 尽量使用TINYINT.SMALLINT

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化 前言: 很多人都认为性能是在通过编写代码(程序代码或者是数据库代码)的过程中优化出来的,其实这是一个非常大的误区.真正影响性能最大的部分是在设计中就已经产生了的,后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已,而且能够解决的问题通常也比较有限.本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效,尽可能减少后期的烦恼. 9.1 高效的模型设计 最规范的就一定

MySQL 大表优化方案探讨

当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT.SMALLINT.MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的