sql优化

一、MySQL 会遇到的问题： 　　1、 高并发的读写效率低问题 ---- 解决方案：集群，分布式。 　　2、 海量数据的读写效率低问题 ----- 解决方案：分表，分库。 　　3、 高可用和高扩展 ---- 解决方案：动态扩展服务器、防止单点故障、容灾。 二、关系型数据库优化：（原则： 先单机，后多机。 ） 　　2.1 单机 优化方案 ： 　　　　1.慢SQL的定义--> 分析慢SQL -- 解决慢SQL。 　　　 　　　　2. 表的设计、索引、引擎的优化。 　　3. 分表(垂直分表、水平分表)、分区、分库 的优化。 　　 4. 缓存做集群。 　　　　5.SQL语句优化 　　 　　2.2 多机优化方案 （分为多个数据库）： 　　　　1. 读写分离（要保证 主从同步 ）： 　　　　　　 28 原则：如果有10个数据库，则 2 个专门做增删改的数据库， 8 个专门做查询的数据库。 　　　　2. 缓存做集群 三、定位慢SQL 　 　　3.1 查看数据库状态： 　　　　3.1.1 查看运行时间： show status like ‘uptime’; 　　　　3.1.2 CRUD 执行次数： 　　　　　　Show status like ‘Com_%’; 　　　　　　Show status like ‘Com_update%’ 　　　　　　Show status like ‘Com

1、索引是做什么的? 想象一下，你面前有本词典，数据就是书的正文内容，你就是那个cpu，而索引，则是书的目录 索引用于快速找出在某个列中有一特定值的行。不使用索引，MySQL必须从第1条记录开始然后读完整个表直到找出相关的行。 表越大，花费的时间越多。如果表中查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要看所有数据。 大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B树中存储。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。 2、索引越多越好？ 大多数情况下索引能大幅度提高查询效率，但： 数据的变更（增删改）都需要维护索引，因此更多的索引意味着更多的维护成本 更多的索引意味着也需要更多的空间 （一本100页的书，却有50页目录？） 过小的表，建索引可能会更慢 （读个2页的宣传手册，你还先去找目录？） 3、索引的字段类型问题 text类型，也可建索引（需指定长度） myisam存储引擎索引键长度综合不能超过1000字节 用来筛选的值尽量保持和索引列同样的数据类型 尽量减少like，但不是绝对不可用，"xxxx%" 是可以用到索引的， 想象一下，你在看一本成语词典，目录是按成语拼音顺序建立，查询需求是，你想找以 "一"字开头的成语（"一%"），和你想找包含一字的成语（"%一%"）

本文部分内容摘 自《SQL Server 2008管理实战》，人民邮电出版社；《深入MSSQL 2008升级和应用程序的兼容性》，IT专家网；《SQL Server 2008联机丛书》 ，主要整理了如何把SQL Server 2000/2005升级到2008。 如果系统不大，数据库设计简单，只有单纯的数据表，其他数据库对象不多，且应用系统设计不复杂，你也许可以直接将数据库复制或备份，再到SQL Server 2008执行附加或还原数据库，然后更新索引统计，设置数据库兼容性。或是通过安装程序，就地将SQL Server2000/2005直接升级到SQL Server 2008即可。但如果数据库庞大，系统复杂，则最好先完成升级测试后，再按照系统需求，拟定升级计划，照计划一步步实施。 一般情况下，SQL Server 2005与SQL Server 2008的版本兼容性相当高，2005升级到2008一般没什么问题。但2000升级到2008版本，可能需要先行测试，这两者差异比较大，包括：服务器 内置的系统对象、T-SQL语法定义、新增的关键词、禁用的功能等，相距两版后较会有兼容性的问题。 在升级测试之前应先评估需求，列出有用到哪些功能，如数据库引擎、Analysis Services、Reporting Services、SSIS/DTS、丛集等大项，以及Replication、Log

性能调优相关文档书籍 http://dev.mysql.com/doc/refman/5.7/en/group-by-optimization.html http://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html 《MySQL性能调优与架构设计》 SQL查询优化总结 缺失索引，查询速度差别是100倍：首先应考虑在 where 及 order by 涉及的列上建立索引 1 show index from mb_ransomrequestform; 2 ALTER TABLE mb_ransomrequestform ADD INDEX IDX_corporationid (corporationid); 3 drop index IDX_corporationid on mb_ransomrequestform; View Code 避免在 where 子句使用不能使用索引的操作符，比如!=、<>、like “%xx%”、or。否则将导致引擎放弃使用索引而进行全表扫描。 1)like “%xx%”改成like “xxx%”可以使用索引 mysql> select bill.billId from EE_PawnBill bill, EE_PawnerInfo pawner where bill.pawnerid

java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction问题 1.问题描述 　　执行了几条update语句之后的，再执行其他的update语句，后台就报如下错误： <-- java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4120) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4052) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2503) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2664) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2794) at com.mysql

http://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html 这段时间mysql 数据库的性能明显降低,iowait达到了30, 响应时间明显变长. 通过show processlist 查看,发现有很多session在处理sort 操作, 跟DBA一起调试优化,增大sort_buffer_size 好象效果也不大, 通过查看监控,也没发现有硬盘排序. 我怀疑是sort导致性能下降,固让开发修改程序, sort由程序来处理. 星期五发布后,今天发现压力固然好了很多. 因此基本上能确定是sort引起的问题. 今天仔细分析问题,查看mysql的参数时,看到一个叫做 max_length_for_sort_data 的 参数, 值是1024 仔细查看mysql 的filesort算法时, 发现mysql的filesort有两个方法,MySQL 4.1之前是使用方法A, 之后版本会使用改进的算法B, 但使用方法B的前提是列长度的值小于 max_length_for_sort_data, 但我们系统中的列的长度的值会大于1024. 因此也就是说在sort的时候, 是在使用方法A, 而方法A的性能比较差, 也就解释了我们的mysql系统在有sort时,性能差,去掉之后性能马上提高很多的原因. 马上修改 max_length

SQL版本 5.7 有一张流水表，未分库分表，目前的数据量为950w，分页查询使用到了limit，优化之前的查询耗时167s左右 (execution: 16s831ms, fetching: 107 ms) 按照下文的方式调整SQL后，耗时347ms (execution: 163 ms, fetching: 184 ms)；优化前的SQL类似这样： -- 优化前SQL SELECT 各种字段 FROM `table_name` WHERE 各种条件 LIMIT 0,10; --优化后 SELECT * FROM `table_name` a RIGHT JOIN ( SELECT id FROM `table_name` where 条件 LIMIT 0,1000000 ) temp_table ON temp_table.id = a.id 来源： https://www.cnblogs.com/gjths/p/12234092.html

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20 可以这样查询： select id from t where num=10 union all select id from t where num=20 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. 很多时候用 exists 代替 in

逻辑分层 下面是MySQL的逻辑分层图： 连接层：连接与线程处理，这一层并不是MySQL独有，一般的基于C/S架构的都有类似组件，比如连接处理、授权认证、安全等。 服务层：包括缓存查询、解析器、优化器，这一部分是MySQL核心功能，包括解析、优化SQL语句，查询缓存目录，内置函数（日期、时间、加密等函数）的实现。 引擎层：负责数据存储，存储引擎的不同，存储方式、数据格式、提取方式等都不相同，这一部分也是很大影响数据存储与提取的性能的；对存储层的抽象。 存储层：存储数据，文件系统。 存储引擎 查看数据库支持的存储引擎：show engines; 如果要想查看数据库默认使用哪个引擎，可以通过使用命令： show variables like '%storage_engine%'; InnoDB，MyISAM的主要区别： InnoDB：在MySQL5.5开始作为默认的存储引擎，支持事务，行级锁，适合高并发场景，XA协议支持分布式事务， 事务优先 。 MyISAM：不支持事务， 性能优先 ，表级锁，不适合高并发场景。 sql执行顺序： https://www.cnblogs.com/annsshadow/p/5037667.html explain-执行计划 explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 使用方法

一直对SQL优化的技能心存无限的向往，之前面试的时候有很多面试官都会来一句，你会优化吗？我说我不太会，这时可能很多人就会有点儿说法了，比如会说不要使用通配符*去检索表、给常常使用的列建立索引、还有创建表的时候注意选择更优的数据类型去存储数据等等，我只能说那些都是常识，作为开发人员是必须要知道的。但真正的优化并不是使用那些简单的手法去完成实现的，要想知道一条SQL语句执行效率低的原因，我们可以借助MySQL的一大神器---"EXPLAIN命令"，EXPLAIN命令是查询性能优化不可缺少的一部分，本文在结合实例的同时会总结explain命令的使用及相关参数的说明。 首先说说我这次浴火重生的优化初衷吧，上个月在公司完成的统计模块中，其中就有几条SQL语句执行的速度稍微有点慢，心里一直留了一道坎。直到昨天晚上在家看了一篇文章，是关于MySQL优化的对EXPLAIN命令的详解，所以今天一到公司就想着把之前那些SQL语句的病赶紧给看看，虽然，我没有达到那种秒查的效果，但是优化的效果还是有明显的提升。 业务场景： 分区 统计XXX省 每月 上传数据的企业数量，何为企业是否是未上传数据，即专门存放上传数据的数据表中没有记录的为未上传数据的企业，如果有那么代表已经上传数据。 下面是我之前写的SQL语句(未优化前的)，它执行的时间是 2.318sec ，并且使用EXPLAIN命令进行分析：