sql优化

导读 MySQL是一个开放源码的小型关联式数据库管理系统，开发者为瑞典MySQL AB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。 可能有人会惊奇MySQL为何从5.x一下跳跃到了8.0。事实上，MySQL 5.x系列已经延续了很多年，从被Oracle收购之前就是5.1，而收购之后一直维持在5.x，比如5.5，5.6，5.7等等。其实，如果按照原本的发布节奏，可以把5.6.x当成6.x，5.7.x当成7.x。所以，只是换了版本命名方式而已。 MySQL 8.0.0亮点 事务住数据字典，完全脱离了MylSAM存储引擎 真正将数据字典放到了1nnoOB中的一些表中，夕J长下再需要FRM、TRG、pAR文件啦！Inf rmationSchema现在以数据字典表的一个视图出现。原则上可以完全不需要MylSAM数据 表类型了，所有的系统表都可以放到Inn0OB之中。 SQL角色 角色是一系列叹限的集台。可以创建角色，给莫个用户授子和去除角色。这对于权限管理 很方便。 uttsmb4字芍集将成为默认字符集，并支持Unicode 9 默认字符集将从1atinl改为uttsmb4，默认走序collatlon将从latlnl_swedish

MySQL部署之源码安装 安装依赖包 注： 相关依赖包的作用 cmake ： 由于从MySQL5.5版本开始弃用了常规的configure编译方法，所以需要CMake编译器，用于设置mysql的编译参数。如：安装目录、数据存放目录、字符编码、排序规则等。 Boost #从MySQL 5.7.5开始Boost库是必需的，mysql源码中用到了C++的Boost库，要求必须安装 源码安装 与二进制 ( RPM ) 发行版本相比，如果我们选择了通过源代码进行安装，那么在安装过程中我们能够对MySQL 所做的调整将会更多更灵活一些。因为通过源代码编译我们可以： a ) 针对自己的硬件平台选用合适的编译器来优化编译后的二进制代码； b ) 根据不同的软件平台环境调整相关的编译参数； c ) 针对我们特定应用场景选择需要什么组件不需要什么组件； d ) 根据我们的所需要存储的数据内容选择只安装我们需要的字符集 ( utf-8 ) ； e ) 同一台主机上面可以安装多个MySQL； 在源码安装给我们带来更大灵活性的同时，同样也给我们带来了可能引入的隐患： a ) 对编译参数的不够了解造成编译参数使用不当可能使编译出来的二进制代码不够稳定； b ) 对自己的应用环境把握失误而使用的优化参数可能反而使系统性能更差； c ) 还有一个并不能称之为隐患的小问题就是源码编译安装将使安装部署过程更为复杂

前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢，影响业务流程。本文从SQL角度进行数据库优化，提升SQL运行效率。 判断问题SQL 判断SQL是否有问题时可以通过两个表象进行判断： 系统级别表象 CPU消耗严重 IO等待严重 页面响应时间过长 应用的日志出现超时等错误 可以使用sar命令，top命令查看当前系统状态。 也可以通过Prometheus、Grafana等监控工具观察系统状态。（感兴趣的可以翻看我之前的文章）640?wx_fmt=png SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解，一段SQL太长阅读性肯定会差，而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手，如下所示：640?wx_fmt=png 执行计划告诉我们本次查询走了全表扫描Type=ALL，rows很大(9950400)基本可以判断这是一段"有味道"的SQL。 获取问题SQL 不同数据库有不同的获取方法，以下为目前主流数据库的慢查询SQL获取工具 MySQL 慢查询日志 测试工具loadrunner Percona公司的ptquery等工具 Oracle AWR报告 测试工具loadrunner等 相关内部视图如v$、$session

在日常工作中，我们有时会开慢查询去记录一些执行时间比较久的SQL语句，找出这些SQL语句并不意味着完事了，此时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描。所以我们深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。（QEP：sql生成一个执行计划query Execution plan） mysql> explain select * from servers; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL |

sql语句的实质行为就是从磁盘上的文件中读取数据，数据在磁盘上存储是随机IO，效率较低，所以我们需要“索引”B+tree 数据存储时是以页为单位存储的 为什么不用HashTable、二叉树？ HashTable的存储原理是：HashTable的底层也是数组，根据一定算法将key转化成下标，存储至数组中，查询是直接根据key算出下标从数据中拿到数据，K-V的结果不适合存储复杂数据结构的数据，比如一条数据中有多个字段需要存储，另外HashTable的存储顺序是随机的，不能查询大于、小于，只适合精确查找。 完全对称二叉树为什么不合适？ 因为二叉树存储是有序的，完全对称二叉树可以做大于、小于的运算，但是在查找过程中要回去查找父节点中储存的元素，不利于检索 B+tree B+tree也是有序的，在存储过程中是将所有非叶子节点的数据冗余一份到叶子节点中，在查找过程中只关注同级节点就可以了，所以B+tree的有点就在于区间查询，另外B+tree中一个节点存储了多个元素，有助于节省磁盘IO次数。 聚合索引：新建表是默认分配1页资源，索引与数据存在一起，插入数据达到本页最大限制时（默认16k），将第一页复制一份，并开辟一页新的资源，原第一页修改为目录页，以此类推，B+tree形成 ，建表时的第一页目录通常会被缓存，数据量越大，缓存越多。所以建表时务必指定主键索引，如果没有指定，也没有建其他唯一索引

很多时候受限于资源限制，需要在单机上安装多个MySQL实例。 本文基于MySQL 5.7.27，介绍如何在单机环境下安装多个MySQL实例。 文件的方案，建立了3个实例，端口分别为3306, 3307, 3308。 1.创建MySQL用户账号 首先创建mysql用户组和用户。 并设置不允许登录。 # groupadd mysql # useradd -s /sbin/nologin -g mysql -M mysql -s/sbin/nologin表示禁止该用户登录，只需要角色存在即可，加强安全。 -g mysql指定mysql用户属于mysql组。 -M表示不创建用户家目录。 2.安装 2.1下载安装文件 下载地址 https://downloads.mysql.com/archives/community/ 版本 5.7.27 二进制安装文件 mysql-5.7.27-linux-glibc2.12-x86_64.tar.gz 2.2 解压安装文件 解压二进制文件，移动到指定目录，并创建软链接。 [root@localhost tmp]# tar zvxf mysql-5.7.27-linux-glibc2.12-x86_64.tar.gz [root@localhost tmp]# mkdir -p /application [root@localhost tmp]# mv

1. QPS(每秒Query量) QPS = Questions(or Queries) / seconds mysql > show global status like 'Question%'; 2. TPS(每秒事务量) TPS = (Com_commit + Com_rollback) / seconds mysql > show global status like 'Com_commit'; mysql > show global status like 'Com_rollback'; 3. key Buffer 命中率 mysql>show global status like 'key%'; key_buffer_read_hits = (1-key_reads / key_read_requests) * 100% key_buffer_write_hits = (1-key_writes / key_write_requests) * 100% 4. InnoDB Buffer命中率 mysql> show status like 'innodb_buffer_pool_read%'; innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read

1.永远是小表驱动大表 优化原则： 2.优化order by 语句 order by子句，尽量使用Index方式排序，避免使用FileSort方式排序。尽可能在索引列上完成排序操作，遵照索引建的最佳左排序 优化策略： *增大sort_buffer_size参数设置 *增大max_length_for_sort_data参数设置 order by 关键字优化： 1.Order by 时select*是一个大忌只Query需要的字段，这点非常重要，在这里的影响是： （1）当Query的字段大小总和小于max_length_for_sort_data，而且排序字段不是TEXT|BLOB类型，会用改进后的算法-----单路排序，否则用老算法----多路排序 （2） 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O,但是用单路排序的风险会很大一些，所以要提高sort_buffer_size。 2.尝试提高sort_buffer_size **不管用哪种算法，提高这个蚕食都会提高效率，当然要根据系统的能力去提高 3.尝试提高max_length_for_sort_data 提高这个参数，会增加用改进算法的概率，但是如果设的太高，数据总容量超过sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率

这是你的表结构，有三个字段，分别是id,name,cid CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `cid` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name_cid_INX` (`name`,`cid`),) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8 索引方面：id是主键，(name,cid)是一个多列索引。 ----------------------------------------------------------------------------- 下面是你有疑问的两个查询： EXPLAIN SELECT * FROM student WHERE cid=1; EXPLAIN SELECT * FROM student WHERE cid=1 AND name='小红'; 你的疑问是：sql查询用到索引的条件是必须要遵守最左前缀原则，为什么上面两个查询还能用到索引？ --------------------------------------------------------------------

一、Mysql的逻辑架构 二、存储引擎 Mysql5.5之前，默认存储引擎是MyISAM，5.5之后默认存储引擎变成 InnoDB 。 MyISAM和InnoDB的区别： 1）MyISAM不支持事务、InnoDB支持事务 2）MyISAM只有表锁、InnoDB引入了行锁 3）MyISAM支持全文索引、InnoDB 5.5不支持，5.6以后支持 4）MyISAM的读写速度会优于InnoDB 三、MySQL优化（SQL优化） · 数据类型的优化（创建表的时候，选择合适的数据类型） · 索引优化（SQL优化成本最低并且最有效果的优化方式） · 查询优化（SQL自带的检测工具、SQL结构） · 库表结构优化（分库分表、读写分离） · 硬件优化（cpu、固态硬盘、内存） · 参数优化（系统运行参数）- DBA 四、数据类型的优化 数据类型的选择原则： · 选择最小的数据类型，同时需要保证能够放下所存储的数据 · 选择最合适的数据类型，比如使用int表示年龄，而是不是varchar表示年龄 · 尽量让需要添加索引的列为not null 五、索引优化 什么是索引？ 索引是一本书的目录，可以快速找到相应的内容。 索引是一个帮助我们快速查询内容的 数据结构 。 　 无索引的查询方式： 有索引的查询方式： 索引失效： 当写了一个索引后，开发者认为执行的sql会用上该索引