sql优化

获取锁等待情况 可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定争夺： mysql> show status like 'Table%'; +----------------------------+----------+ | Variable_name | Value | +----------------------------+----------+ | Table_locks_immediate | 105 | | Table_locks_waited | 3 | +----------------------------+----------+ 2 rows in set (0.00 sec) 可以通过检查Innodb_row_lock状态变量来分析系统上的行锁的争夺情况： mysql> show status like 'innodb_row_lock%'; +----------------------------------------+----------+ | Variable_name | Value | +----------------------------------------+----------+ | Innodb_row_lock_current_waits | 0 | |

通过查询缓存实现(适合用于更新操作不多的数据表，在MySql高版本中查询缓存已经被删除了) 使用命令优化 1、根据慢日志定位满查询日志 show variables like '%slow_query_log%'; 慢查询日志的定义是当一个查询的时间超过设定的时间就会被加入慢查询日志中，所以设置定义慢查询时间的时候一定要慎重。 2、使用explain等工具分析sql explain select id,name from student where name = "zhangsan"; 3、修改sql或者尽量让sql走索引 来源： https://www.cnblogs.com/we9999/p/12393730.html

建议先看看 开发人员MySQL调优-实战篇0 让执行的SQL使用索引 虽然DBA给我们建了很多索引，但没有经验的开发人员往往只看表结构，不太关注索引和如何利用索引提高SQL执行速度，下面罗列一些经验，让你写的SQL更加高效的利用索引 在做实验之前最好先想一想索引的数据结构与排序，以及索引工作的方式，才能更快的理解与记住这些点，否则在工作中遇到更复杂的情况，很可能就不会处理了 查询字段与某一个索引的结构完全一致，包括字段和顺序（完全匹配） create index idx_tv_v_user_u_a_g on tb_v_user(user_name,age,gendor); select * from tb_v_user where user_name = '1F7sJ' and age = 44 and gendor = 1; 查询条件与索引的列与顺序完全一致，执行计划扫描类型为ref。有兴趣的同学可以试试分别将user_name、age、gendor查询条件删除，看看执行计划是什么情况 不在列上做任何附加操作，比如加函数 select * from tb_v_user where left(user_name,5) = '1F7sJ' and age=44 and gendor = 1; 这里的SQL和上面的SQL执行结果是一模一样，写法上区别是在user

MySQL 的基本架构示意图 MySQL 可以分为 Server 层和存储引擎层两部分。 server Server 层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核 心服务功能，以及所有的内置函数(如日期、时间、数学和加密函数等)，所有跨存储引 擎的功能都在这一层实现，比如存储过程、触发器、视图等。 存储引擎 存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、 MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。 连接器 连接器负责跟客户端建立连接、获取权限、维持和管理连接 注意: 一个用户成功建立连接后，即使你用管理员账号对这个用户的权限做了修 改，也不会影响已经存在连接的权限。修改完成后，只有再新建的连接才会使用新的权限设置。 长链接: 数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。 短连接则是指每次执行完很少的几次查询就断开连接，下次查询再重新建立一个。 建立连接的过程通常是比较复杂的，所以我建议你在使用中要尽量减少建立连接的动作，也就是尽量使用长连接。 查询缓存 执行步骤1:查询缓存 MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前 执行过的语句及其结果可能会以

写在前面：无规矩不成方圆。对于刚加入互联网的朋友们，肯定会接触到 MySQL ， MySQL 作为互联网最流行的关系型数据库产品，它有它擅长的地方，也有它不足的短板，针对它的特性，结合互联网大多应用的特点，笔者根据自己多年互联网公司的 MySQL DBA 经验，现总结出互联网 MySQL 的一些开发规范，仅供参考。 一、基础规范 (1) 使用 INNODB 存储引擎 (2) 表字符集使用 UTF8 (3) 所有表都需要添加注释 (4) 单表数据量建议控制在 5000W 以内 (5) 不在数据库中存储图 ⽚ 、文件等大数据 (6) 禁止在线上做数据库压力测试 (7) 禁 ⽌ 从测试、开发环境直连数据库 二、命名规范 (1) 库名表名字段名必须有固定的命名长度， 12 个字符以内 (2) 库名、表名、字段名禁 ⽌ 止超过 32 个字符。须见名之意 (3) 库名、表名、字段名禁 ⽌ 止使 ⽤ 用 MySQL 保留字 (4) 临时库、表名必须以 tmp 为前缀，并以 ⽇ 日期为后缀 (5) 备份库、表必须以 bak 为前缀，并以日期为后缀 三、库、表、字段开发设计规范 (1) 禁 ⽌ 使用分区表 (2) 拆分大字段和访问频率低的字段，分离冷热数据 (3) 用 HASH 进 ⾏ 散表，表名后缀使 ⽤⼗ 进制数，下标从 0 开始 (4) 按日期时间分表需符合 YYYY[MM][DD][HH]

通常，当 Microsoft JDBC Driver for SQL Server 执行查询时，驱动程序会将服务器中的所有结果检索到应用程序内存中。尽管这种方法可以最大程度地减少 SQL Server 上的资源占用，但它可能会在 JDBC 应用程序中针对生成非常大的结果的查询引发 OutOfMemory （OOM）错误 。 查询二进制对象或者海量数据（本文桐城大数据）的结果集时，查询的响应时间更长，更容易出现OOM的问题， SQL Server 作为成熟的数据库，有自己的解决方式，本文主要讨论java中的实现： 一、通过数据库游标的方式，控制结果集的每次返回的结果大小， 来降低大数据查询的资源消耗和响应时间 ： 1.使用SQL Server JDBC的URL为 selectMethod=cursor类型（默认 selectMethod= direct）： String url="jdbc:sqlserver://127.0.0.1;databaseName=lyy;selectMethod=cursor"; 这种方式会对所有使用该url的连接下的所有查询起作用，可能引起其他普通情况的读取性能下降。 2.设置Fetch Size，要想该设置起效必须使用 SQLServerResultSet.TYPE_SS_SERVER_CURSOR_FORWARD_ONLY类型的Statement：

一、说明 假期有时间可以多去看看一些表的设计，发现了不少问题，老系统上过百的字段，里面含有大量的mediumtext，不到500万的数据量，开发规范中有要求表设计不要超过500万数据量。查看了表占用的磁盘空间120G，毫无疑问是大表，当初设计的时候就没有考虑过设计。一句话上线能用就行，管他呢。 二、MySQL规范 1、单表不要超过500万条记录，同时评估单表所占用磁盘空间不要超过50G，否则考虑优化、分表等。 2、禁用text字段类型，如果必须的用，也需要单独设计表。 三、禁用text字段类型原因 1、性能很差，排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。 2、TEXT或BLOB类型只能使用前缀索引，MySQL对索引字段长度是有限制的。 四、解决办法 定好规范，严格执行（执行很难），一两个DBA面对几十上百的业务系统，几万个表，上百万的字段通过每一个表和字段人工审核是不可能完成的，最终还是要靠智能化的审核系统！ 来源： 51CTO 作者： roidba 链接： https://blog.51cto.com/roidba/2474403

SQL Server2008查询性能优化笔记 第一章就说到了Sql Server性能杀手，其中第一条是低质量的索引。 他的前提是在硬件和操作系统都已经优化的情况下，我的服务器内存有12G，但是sql server才用到1G，先边看书边配置了。 低质量的索引这一点我感同身受，当时任务比较紧急，没有来得及记录数据。 总之，原来数据库根本没有索引，基本上服务器处于崩溃状态，Sql server CPU占用率100%。 由于很久没搞数据库，学校学习的那点东西都忘光了，重新回来，第一个找到了sql server查询分析器这个东东，把一些表加了索引，一下服务器就正常了，汗（我开始一直因为是程序insert太多的问题，正在写一个memcached的版本来替换，不过后续还是要做的）。 书是图书馆的，以后还了就找不到了，就到博客上做些记录吧。 性能杀手 1. 低质量的索引 2. 不精确的统计 3. 过多的阻塞和死锁 4.不基于数据集操作，通常是T-Sql游标 5.低质量的查询设计 6.低质量的数据库设计 7.过多的碎片 8.不可重用的执行计划 9. 低质量的执行计划,通常是因为参数嗅探所导致的 10.执行计划频繁重编译 11. 游标的错误使用 12. 数据库日志的错误配置 13. 过多使用或者错误配置tempdb 我已经在我的表上建立了索引，速度已经大大加快了，从CPU 占用99%，

博文大纲： 一、PXC介绍 二、部署PXC集群 一、PXC介绍 参考： Percona官方 PXC是一个开源的MySQL高可用解决方案，它将Percona Server和Xtrabackup与Galera库集成，以实现同步多主复制。基于Galera的高可用方案主要有MariaDB Galera Cluster（MGC）和Percona XtraDB Cluster（PXC），目前PXC架构在生产环境中用的更多而且更成熟些，PXC相比那些传统的基于主从模式的集群架构MHA和双主，PXC最突出的特点就是解决了诟病已久的复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，它们互相的关系是对等的。本身Galera Cluster也是一种多主架构。PXC是在存储引擎层实现的同步复制，而非异步复制，所以其数据的一致性是相当高的。 其工作原理如下： 要搭建PXC架构至少需要三台MySQL实例来组成一个集群，三个实例之间不是主从模式，而是各自为主，所以三者之间的关系是对等的，不分主从，这也叫multi-master架构，客户端读写时，连接哪个实例都是一样的，读取到的数据是相同的，写入任意一个实例后，集群会将自己新写入的数据同步到其他实例上，这种架构不共享任何数据，是一种高冗余的MySQL集群架构。 1、PXC优缺点 优点： 实现了MySQL集群的高可用性和数据的强一致性。

MySQL提供了两种存储引擎：MyISAM和 InnoDB，MySQL4和5使用默认的MyISAM存储引擎。从MYSQL5.5开始，MySQL已将默认存储引擎从MyISAM更改为InnoDB。 MyISAM没有提供事务支持，而InnoDB提供了事务支持。 建议设置 default-storage-engine=InnoDB ，强烈建议不要再使用MyISAM引擎。 调整 innodb_buffer_pool_size 的大小，如果是单实例且绝大多数是InnoDB引擎表的话，可考虑设置为物理内存的50% -70%左右。 设置 innodb_file_per_table = 1 ，使用独立表空间。 调整 innodb_data_file_path = ibdata1:1G:autoextend，不要用默认的10M,在高并发场景下，性能会有很大提升。 设置 innodb_log_file_size= 256M，设置innodb_log_files_in_group=2，基本可以满足大多数应用场景。 调整 max_connection （最大连接数）、 max_connection_error （最大错误数）设置，根据业务量大小进行设置。 另外， open_files_limit、innodb_open_files、table_open_cache、table_definition