sql优化

基准测试是一种测量和评估软件性能指标的活动用于建立某个时刻的性能基准,以便当系统发生软硬件变化时重新进行基准测试以评估变化对性能的影响,是针对系统设置的一种压力测试。 基准测试特点 直接、简单、易于比较,用于评估服务器的处理能力 可能不关心业务逻辑,所使用的查询和业务的真实性可以和业务环境没关系 压力测试特点 对真实的业务数据进行测试,获得真实系统所能承受的压力 需要针对不同主题,所使用的数据和查询也是真实用到的 基准测试是简化了的压力测试 基准测试的目的 建立MySQL服务器的性能基准线,确定当前MySQL服务器运行情况,确定优化之后的效果 模拟比当前系统更高的负载,已找出系统的扩展瓶颈,可以增加数据库并发,观察QPS(每秒处理的查询 数),TPS(每秒处理的事务数)变化,确定并发量与性能最优的关系 测试不同的硬件、软件和操作系统配置 证明新的硬件设备是否配置正确 如何进行基准测试 对整个系统进行基准测试: 优点 能够测试整个系统的性能,包括web服务器缓存、数据库等 MySQL并不总是出现性能问题的瓶颈,如果只关注MySQL可能忽略其他问题,能反映出系统中各个组件接口间的性能问题体现真实性能状况 缺点 基准测试最重要的就是简单,可能对不同的方案进行测试,找到最优的方案,基准测试进行的时间一定要短,否则就要花费大量的时间进行基准测试 测试设计复杂,消耗时间长

table_open_cache 表打开缓存 mysql> show variables like 'table_open%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | table_open_cache | 400 | 相关变量 mysql> show global status like 'open%_tables'; +---------------+--------+ | Variable_name | Value | +---------------+--------+ | Open_tables | 384 | 打开的缓存表数量 | Opened_tables | 768975 | 打开的所有表数量 =============================================== table_open_cache 这个参数设置多少合适呢？ ——肯定不是越大越好，太大了会占用太多文件描述符，描述符用尽会导致无法建立新连接。那这么设置这个值呢？ 1. 根据Open_tables，这个参数接近table_open_cache，说明缓冲池快满了 2. Opened_tables还一直在增加

　　百万数据量SQL，在进行分页查询时会出现性能问题，例如我们使用PageHelper时，由于分页查询时，PageHelper会拦截查询的语句会进行两个步骤 　　1.添加 select count（*）from （原查询sql） ，用于统计查询的总数 　　2.拼接 limit startPage，number 用于分页 　　 　　此时有两个问题 　　　　第一个问题是： 　　　　　　用于统计的 select count（*）from （原查询sql）在数据量大时速度慢 　　　　第二个问题时： 　　　　　　limit startPage，number 在大数据量时效率低 　　 　　解决方案： 　　　　第一个问题： 　　　　　　在数据量过大时，不使用分页插件PageHelper，select count（*）from （原查询sql）固定返回一个固定值给到前端，例如千万级数据，固定返回1千万 　　　　第二个问题： 　　　　　　在数据量过大时，不使用分页插件PageHelper ，使用join或者子查询去优化 　　　　　　例如 id为主键，name为非唯一索引 　　　　　　　　优化前： 　　　　　　　　select id,name,brand from table where name=‘xxx’ limit 100000，10 　　　　　　　　优化后： 　　　　　　　　select aa

一、SQL语句优化 （1）使用limit对查询结果的记录进行限定 （2）避免select *，将需要查找的字段列出来 （3）使用连接（join）来代替子查询 （4）拆分大的delete或insert语句 二、选择合适的数据类型 （1）使用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob （2）使用简单的数据类型，整型比字符处理开销更小，因为字符串的比较更复杂。如，int类型存储时间类型，bigint类型转ip函数 （3）使用合理的字段属性长度，固定长度的表会更快。使用enum、char而不是varchar （4）尽可能使用not null定义字段 （5）尽量少用text，非用不可最好分表 三、选择合适的索引列 （1）查询频繁的列，在where，group by，order by，on从句中出现的列 （2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列 （3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好 （4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高： mysql> SELECT COUNT(DISTINCT column_name) FROM table_name;

服务器性能剖析 1、性能指标 基准测试是针对系统设计的一种压力测试。 吞吐量: 单位时间内的事务处理数(TPS) 响应时间或延迟 并发性 可扩展性 SHOW STATUS 和SHOW PROCESSLIST 命令 tcpdump Schema与数据类型优化 数据类型选择 更小的通常更好，占用更少的磁盘、内存和CPU缓存。 简单就号，占用更少的CPU周期。如整型比字符操作代价更低。 尽量避免NULL。查询中包含NULL列，优化会更困难，索引、索引统计和值都会变的复杂。可为NULL的列会使用更多的存储空间。 如果计划在列中建索引，应尽量避免可谓NULL的列。 BLOB和TEXT区别在于BLOB存储的是二进制数据，没有排序规则和字符集，而TEXT类型有字符集和排序规。MySQL只对每个列的最前max_sort_length字节做排序。不能将列全部长度做索引，也不能使用这些索引消除排序。如果EXPLAIN执行计划中Extra列包含“Using temporary” 则说明这个查询使用了隐式临时表。 schema设计 不可有太多的列: 存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后再服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的。 不可进行太多的关联: 单个查询最好再12个表以内做关联。在设计的时候最好向单表查询靠拢

子查询 子查询是 MySQL4.1 提供的新功能，在此之前需要使用表的连接查询来实现子查询的功能。在多数情况下，表的连接查询可以优化子查询效率较低的问题。 所谓子查询是指将一个查询（内层查询）语句嵌套在另外一个查询（外层查询）语句中，内层查询语句的结果为外层查询语句提供查询条件，内层查询要先于外层循环执行。 标量子查询 标量子查询指的是子查询（内层查询）返回的结果是一个单一值的标量，如一个数字或者一个字符串，这种方式是子查询中最简单的返回形式。在标量子查询中可以使用“>”、 “>=”、“<”、“<=”、“=”、“<>”或者“!=”这些比较运算符对子查询的标量结果进行比较，通常子查询的位置在比较式的右侧。 select * from emp where sal > ( select sal from emp where ename = 'Clark' ) ; 行子查询 行子查询指的是子查询（内层查询）返回的结果集是一行 N（N>=1）列，该结果集通 常来自于对表中某条记录的查询。在行子查询中也可以使用“>”、“>=”、“<”、“<=”、 “=”、“<>”或者“!=”这些比较运算符对子查询的结果进行比较，通常子查询的位置在比较式的右侧。 select * from emp where ( job , deptno ) = ( select job , deptno from emp

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/devcloud/article/details/91802620 欢迎添加华为云小助手微信（微信号： HWCloud002 或 HWCloud003 ），输入关键字“ 加群 ”，加入华为云线上技术讨论群；输入关键字“ 最新活动 ”，获取华为云最新特惠促销。华为云诸多技术大咖、特惠活动等你来撩！ 1. MySQL8.0的版本历史 2016-09-12第一个DM(development milestone)版本8.0.0发布 2018-04-19第一个GA(General Availability)版本开始，8.0.11发布 2018-07-27 下一个GA版本，8.0.12发布 2018-10-22 下一个GA版本，8.0.13发布 2019-01-21 下一个GA版本，8.0.14发布 最新的GA版本为8.0.15，于2019-02-01发布 最近待GA的版本为8.0.16， 8.0.17, 从中可以看出，大概每1~3个月一个版本。 2. MySQL8.0中新增的特性 事务性数据字典 数据字典表以InnoDB表存储字典数据，位于mysql数据库下，对外不可见。有专门的表空间mysql.idb，位于数据目录下

摘自 http://www.cnblogs.com/ATree/archive/2011/02/13/sql_optimize_1.html 1、 首先要搞明白什么叫执行计划？ 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。 可见，执行计划并不是固定的，它是“个性化的”。产生一个正确的“执行计划”有两点很重要： (1) SQL语句是否清晰地告诉查询优化器它想干什么？ (2) 查询优化器得到的数据库统计信息是否是最新的、正确的？ 2、 统一SQL语句的写法 对于以下两句SQL语句，程序员认为是相同的，数据库查询优化器认为是不同的。 select*from dual select*From dual 其实就是大小写不同，查询分析器就认为是两句不同的SQL语句，必须进行两次解析。生成2个执行计划。所以作为程序员，应该保证相同的查询语句在任何地方都一致，多一个空格都不行！ 3、 不要把SQL语句写得太复杂 我经常看到，从数据库中捕捉到的一条SQL语句打印出来有2张A4纸这么长。一般来说这么复杂的语句通常都是有问题的

参考博客：https://www.cnblogs.com/liwenzhou/p/8660826.html Django ORM那些相关操作 一般操作： 看专业的官网文档，做专业的程序员！ 必知必会的13条： <1>all( ) :查询所有结果； <2>filter(**kwargs ) :它包含了匹配所给筛选条件的所有对象； <3>get(**kwargs ) :返回与所给筛选条件相匹配的对象，返回结果有且只有一个，如果符合筛选条件的对象超过一个或者没有都会抛出错误； <4>exclude(**kwargs ) :它包含了与所给筛选条件不匹配的对象； < 5> values(* field): 返回一个ValueQuerySet——一个特殊的QuerySet，运行后得到的并不是一系列model的实例化对象，而是一个可迭代的字典序列 < 6> values_list(* field): 它与values()非常相似，它返回的是一个元组序列，values返回的是一个字典序列 < 7> order_by(* field): 对查询结果排序 < 8> reverse(): 对查询结果反向排序，请注意reverse()通常只能在具有已定义顺序的QuerySet上调用(在model类的Meta中指定ordering或调用order_by()方法)。 < 9> distinct():

mysql优化前情提要 前情提要 慢查询 慢查询日志分析工具： mysqldumpslow工具（mysql自带）： percona-toolkit工具（就比较专业了）： 使用pt-query-digest查看慢查询日志 分析查询语句： 前情提要 如果mysql的性能或者语句执行时间没有达到你的预期，首先你得知道到底是哪条sql语句出了问题，不能把项目里面的sql全部手动走一次再返回来分析吧，这样从人力和时间上都不允许呦，所以，mysql自带了一些功能可以帮助我们定位问题！！！ 慢查询 mysql开启慢查询日志： slow_query_log=ON long_query_time=3 #查询时间多久以上 slow_query_log_file=/var/lib/mysql/slow-log.log 查看mysql慢查询开启情况： show variables like '%slow_query%'; 查看mysql慢查询时间阈值： show variables like 'long_query_time%'; 注：慢查询日志包括被锁阻塞的时间--->Lock_time:~ 慢查询日志分析工具： mysqldumpslow工具（mysql自带）： 例如：得到按照时间排序的前10条里面含有左连接的查询语句： mysqldumpslow -s t -t 10 -g “left join”