sql优化

某厂面试归来，发现自己落伍了！>>> 作者：EneTakane 数据库技术爱好者，爱可生 DBA 团队成员，负责 MySQL 日常问题处理以及数据库运维平台的问题排查，擅长 MySQL 主从复制及优化，喜欢钻研技术问题，还有不得不提的 warship。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 1、SQL 执行流程 看一个问题，在下面这个表 T 中，如果我要执行 select * from T where k between 3 and 5; 需要执行几次树的搜索操作，会扫描多少行？ mysql> create table T ( -> ID int primary key, -> k int NOT NULL DEFAULT 0, -> s varchar(16) NOT NULL DEFAULT '', -> index k(k)) -> engine=InnoDB; mysql> insert into T values(100,1, 'aa'),(200,2,'bb'),\ (300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg'); 这分别是 ID 字段索引树、k 字段索引树 这条 SQL 语句的执行流程： 1.在 k 索引树上找到 k=3，获得 ID=300 2.回表到

目录 1. 需求部分 1.1 基于MySQL复制同步特性，尝试使用Replication的SQL线程来回放binlog，可基于以下逻辑模拟场景 1.2 基于题目1.1，考虑是否可以做到以下场景的恢复 2.操作部分 2.1 环境准备及故障模拟 2.2 数据恢复 2.3 只恢复单个库的数据 2.4 只恢复单个表的数据 2.5 恢复到指定的GTID或position点 2.6 提升恢复效率的参数优化 2.7 使用复制线程与使用mysqlbinlog恢复的效率对比 2.8 总结 1. 需求部分 1.1 基于MySQL复制同步特性，尝试使用Replication的SQL线程来回放binlog，可基于以下逻辑模拟场景 做全量xtrabackup备份模拟日常备份 执行sysbench压测4张表，20个线程，压测10分钟，模拟大量binlog 删除实例模拟数据库被误删除或硬件故障(binlog需要保留) 使用xtrabackup恢复全量备份 使用MySQL Replication SQL线程回放binlog(提示:恢复前需要将relay_log_recocery参数设置为0) 1.2 基于题目1.1，考虑是否可以做到以下场景的恢复 只恢复单个库的数据 只恢复单个表的数据 将数据恢复到指定的GTID或者position点(如恢复到误操作drop之前的GTID) 是否可以通过参数调整提升回放效率

修改mysql配置文件 my.cnf ，内容如下： [mysqld] datadir=/data/mysql/data socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # 设置默认字符集，避免无法输入中文 character_set_server=utf8 init_connect='SET NAMES utf8' # 设置表名不区分大小写 lower_case_table_names=1 # 禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常 处理连接请求 skip-name-resolve # key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意：该参数值设置的过大反而会是服务器整体 效率降低 key_buffer_size = 128M # 限制server接受的数据包大小，对大插入和更新有很大影响 max

简介 MySQL 提供了一个 EXPLAIN 命令, 它可以对 SELECT 语句进行分析, 并输出 SELECT 执行的详细信息, 以供开发人员针对性优化. EXPLAIN 命令用法十分简单, 在 SELECT 语句前加上 Explain 就可以了, 例如: EXPLAIN SELECT * from user_info WHERE id < 300; 准备 为了接下来方便演示 EXPLAIN 的使用, 首先我们需要建立两个测试用的表, 并添加相应的数据: CREATE TABLE `user_info` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL DEFAULT '', `age` INT(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name_index` (`name`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8 INSERT INTO user_info (name, age) VALUES ('xys', 20); INSERT INTO user_info (name, age) VALUES ('a', 21); INSERT INTO user_info (name, age)

1.更小的通常更好。 一般情况下，应该尽量使用可以正确存储数据的最小数据类型。 更小的数据类型通常更快，因为它们占用更少的磁盘、内存和CPU缓存，并且处理时需要的CPU周期也更少。 2.简单就好。 简单数据类型的操作通常需要更少的CPU周期。 例如：整型比字符操作代价更低，因为字符集和校对规则使字符比较比整型比较更复杂。这里有两个例子：一个是应该使用MySQL内建的类型而不是字符串来存储日期和时间，一个是应该用整型存储IP地址。 3.尽量避免NULL。 通常情况下最好指定列为NOT NULL，除非真的需要存储NULL值。 如果查询中包含可为NULL的列，对MySQL来说更难优化，因为可为NULL的列使得索引、索引统计和值比较都更复杂。 通常把可为NULL的列改为NOT NULL带来的性能提升比较小，所以调优时，没有必要首先在现有schema中查找并修改掉这种情况，除非确定会导致问题。如果计划在列上建索引，就应该尽量避免设计成可为NUll的列。 时间和日期上，TIMESTAMP（4个字节）只使用DATETIME（8个字节）一半的存储空间，并且会根据时区变化，具有特殊的自动更新能力。另一方面，TIMESTAMP允许的时间范围要小很多，有时候它的特殊能力会成为障碍。 整数类型： TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT，分别使用8，16，24，32

1.表的设计合理化 2.给搜索字段建立索引 索引提供了高效访问数据的方法，加快了查询的速度。使用所以可以快速的定位到表中的某条记录，从而提高数据库查询的速度，提高数据库的性能。如果查询的时候没有使用索引，查询语句将扫描表中的所有记录。在数据量大的情况下，这样查询的速度会很慢。如果使用索引进行查询，查询语句可以根据索引快速定位到待查询的记录，从而减少查询的记录数，达到提高查询速度的目的。 创建索引： 在执行CREATE TABLE语句时可以创建索引 ALTER TABLE 用来创建普通索引、唯一索引(UNIQUE)、主键索引(PRIMARY KEY)和全文索引(FULLTEXT) 如： ALTER TABLE 表名 ADD INDEX 索引名(字段名) ALTER TABLE 表名 ADD UNIQUE (字段名) ALTER TABLE 表名 ADD PRIMARY KEY (字段名) ALTER TABLE 表名 ADD FULLTEXT (字段名) 也可以使用CREATE创建索引 注意点 :不能用CREATE INDEX语句创建PRIMARY KEY索引 查看索引: show index from 表名 删除索引: drop index index_name on table_name 3.选择正确的存储引擎 Mysql常用的引擎： InnoDB引擎

上一篇文章一起学习Mysql索引二（索引的高性能策略）中我们提到了Mysql5.7版本的一个改进： "索引条件下推"（index condition pushdown）。 那么，今天就让我们来揭开它的神秘面纱。 从ICP（index condition pushdown）的字面意思来看，大家疑惑的点应该就是这个"pushdown"--下推了。 什么是下推，下推到哪里，有什么用？带着疑问，我们先从关闭和开启ICP对一些sql语句的影响，然后再进一步的解答提出的问题。 首先，我们可以通过如下语句开启或关闭Myslq的ICP特性： SET optimizer_switch = 'index_condition_pushdown=off'; //关闭 SET optimizer_switch = 'index_condition_pushdown=on'; //开启 Mysql 新版本默认开启该特性，然后我们准备一张表： CREATE TABLE demo ( id bigint(11) unsigned NOT NULL AUTO_INCREMENT, pid int(11) DEFAULT '0', nid int(5) DEFAULT NULL, country varchar(10) DEFAULT '', name varchar(10) DEFAULT '', status

作者： 壹叶随风 一、博客前言 　　自接触学习MySQL已有一段时间了，对于MySQL的基础知识还是有一定的了解的。在这一路学习过来，每次不管看书还是网上看的资料，对于MySQL数据类型中的时间日期类型总是一扫而过，不曾停下来认认真真的研究学习。最近在图书馆借了一本关于MysQL的书籍，打算全面的学习研究一遍。 　　在之前，我对于时间日期数据类型不怎么感冒，也没怎么用过这一类型。在我的做项目里用到存贮时间的数据，我都是采用int整型数据类型来存储，即是存储时间戳。但是在后面学习MySQL优化的时候，就有一个原则就是存储数据时应采用最小占用空间的数据类型。int类型是4个字节，TIMESTAMP也是4个字节，但是在需要使用日期时，时间戳还需要进一步转换，而TIMESTAMP类型数据就不需要了。 　　所以说认真学习了解每一个知识点是必要的！ 二、时间日期数据类型总概况 　　MySQL中有多种表示时间日期的数据类型，主要有YEAR、TIME、DATE、DATETIME、TIMESTAMP等。每一种数据类型都有存储的时间日期格式、以及取值范围，因此在使用时间日期数据类型的时候需要选取最佳的数据类型。 下图列出了几种数据类型： 三、细讲 1、YEAR 　　year用于存储年，存储时只需要一个字节，插入数据时可以使用各种格式指定YEAR值。 常见的插入格式解析： 　　a、四位字符串或者数字格式

CREATE TABLE t_mobilesms_11 ( id bigint(20) NOT NULL AUTO_INCREMENT, userId varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT ‘’ COMMENT ‘用户id，创建任务时的userid’, mobile varchar(24) NOT NULL DEFAULT ‘’ COMMENT ‘手机号码’, billMonth varchar(32) DEFAULT NULL COMMENT ‘账单月’, time varchar(32) DEFAULT NULL COMMENT ‘收/发短信时间’, peerNumber varchar(64) NOT NULL COMMENT ‘对方号码’, location varchar(64) DEFAULT NULL COMMENT ‘通信地(自己的)’, sendType varchar(16) DEFAULT NULL COMMENT ‘SEND-发送; RECEIVE-收取’, msgType varchar(8) DEFAULT NULL COMMENT ‘SMS-短信; MSS-彩信’, serviceName varchar(256) DEFAULT NULL COMMENT

某厂面试归来，发现自己落伍了！>>> 索引是帮助MySQL高效获取数据的排好序的数据结构 一.存储引擎 这里只讨论 使用最多的两种引擎【MyISAM】和【InnoDB】 1. MyISAM 引擎（非聚集） 上图是是使用myisam引擎的文件，可以看出：MyISAM索引文件和数据是分离的（非聚集）。 当一个查询带有索引，得先通过MYI文件（B+TREE）读取到该条数据的磁盘文件指针，因此再在MYD文件中获取到该条数据。如果查询条件不是索引，则直接去MYD文件去找，做全表扫描，效率低下。 2. InnoDB引擎（聚集） 表数据文件本身就是按B+Tree组织的一个索引结构文件如上图 此为 聚集索引 -叶节点包含了完整的数据记录 1、为什么InnoDB表必须有主键，并且推荐使用整型的自增主键?（ 整型比字符串大小判断效率更高，自增会不容易造成B+Tree分裂 ） 2、为什么非主键索引结构叶子节点存储的是主键值? ( 一致性和节省存储空间 ) 简单总结一下这两个引擎： InnoDB ：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。 MyISAM ：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率