mysql优化

数据类型检测 通过分析数据表的字段信息，进行数据优化。 //查看字段使用状态 SELECT * FROM table_name PROCEDURE ANALYSE()\G 通过这个查询，可以检查数据表字段实际使用的最大长度，最小长度平均长度，枚举信息等信息。可以辅助进行MySQL的优化（数据比较多的时候不要再线上执行）。 表拆分 垂直拆分 说白了就是子表的拆分，比如用户认证的信息一般跟用户的资料信息会拆分称为两个表。资讯类的资讯内容（大文本），与资讯的其余字段会拆分到两个表。 水平拆分 相同的表结构，根据某个字段进行水平拆分。 一般针对数据量非常大的情况进行拆分，选择不同的字段拆分会起到不同的效果。 表分区 详细见前文： MySQL中的表分区 来源： oschina 链接： https://my.oschina.net/u/226106/blog/787464

MySQL体系架构 MySQL中的线程 insert buffer thread：主要负责插入缓冲区的合并操作 read thread：负责数据库读取操作 write thread：负责数据库写操作 log thread：将日志刷新到日志文件中 purge thread：执行purge操作 lock thread：锁控制和死锁检测 通过以下命令查看进程状态： show engine innodb status\G 内存优化 MyISAM 索引块 MyISAM中主要优化索引块缓存，通过合理的优化，让索引读写更高效。 数据快没有提供缓存机制，采用操作系统的IO缓存。 通过设置 key_buffe_size 决定索引块大小，一般设置为可用内存的1/4。 通过以下命令评估索引块使用状况： show status like 'key%'; MySQL为了防止索引块竞争，可以手动创建索引块： //创建新的索引快 set global cache_name.key_buffer_size=1024*512; //让索引使用新的索引快 cache index idx_name,idx_name2 in cache_name; 索引块淘汰 MySQL的索引块采用LRU算法进行淘汰，但是为了防止短期的热数据将长期热数据淘汰掉，MySQL采用了中点插入策略。 将LRU分为两部分：hot和warm

刚刚看了一下2014年中国数据库技术大会（DTCC）PPT，网易杭州研究院的一位同学介绍了一下数据库的优化与调优。 网易的Mysql优化做的很好，而且还写了本书和大家分享这些经验《深入浅出MySQL数据库开发优化与管理维护》。 文章里面大多数写的是我们平常很少想到的硬件方面的优化，还是很深入的。其中提到的 《面向程序员的数据库访问性能优化法则》 引起了我的关注。一直觉得，程序员应该会写好的SQL，就像应该写好的代码一样。我们读过《Effective C++》等语言类的经典书籍，也可以读一下数据库的优化的文章和书籍，例如：《Effective MySQL 之 SQL语句最优化》。 《面向程序员的数据库访问性能优化法则》 从SQL语句，应用到业务上，都给了我们一些建议。其中最核心的应该就是，尽可能减少数据量，减轻延时。 例如 写出具体字段 select a , b ,c from xx，还不是用 select * from xx ； 减少连接次数，使用批量提交，或者使用 select xxx where id in ( 1, 2 , 3 )来查询少量的集合数据，而不用 for i in n{ select xxx from t where id = i ; } 优化业务逻辑，使数据量减到最小；就像我们写for循环的时候，将时间复杂度尽量降低。

接上一篇博客： http://my.oschina.net/twinkling/blog/180619 。确定了表设计： CREATE TABLE `customer` ( `Name` varchar(80) NOT NULL, `CardNo` varchar(10) DEFAULT NULL, `Descriot` varchar(100) DEFAULT NULL, `CtfTp` varchar(4) DEFAULT NULL, `CtfId` varchar(40) DEFAULT NULL, `Gender` varchar(8) DEFAULT NULL, `Birthday` int(9) DEFAULT NULL, `Address` varchar(100) DEFAULT NULL, `Zip` int(10) DEFAULT NULL, `Dirty` varchar(20) DEFAULT NULL, `District1` varchar(6) DEFAULT NULL, `District2` varchar(4) DEFAULT NULL, `District3` varchar(6) DEFAULT NULL, `District4` varchar(6) DEFAULT NULL, `District5` varchar(8) DEFAULT

关于SQL以及索引优化的部分终于学习完了，今天开始进入第二层次的学习，数据库的结构优化，第一部分，选择合适的数据类型。 数据类型的选择，重点在于合适二字。 1. 使用可以存下数据的最小的数据类型 比如，一个时间类型的一个数据，可以使用varchar，可以使用datetime，还可以使用int，如何选择，就看哪一种类型对我们来说是最小的，不言而喻，int类型相对来说是最小的数据类型。 2. 使用简单的数据类型。 int类型要比varchar类型在mysql处理上简单的多，用int类型来存储时间是一个非常好的选择。 3. 尽可能的使用not null来定义字段。 这是因为innodb的一些特性所决定的，对于一些为null的字段，他可能需要一些额外的字段来进行存储，同时也会增加IO和存储的开销，所以在进行表结构设计的时候，尽量把每一个字段设计成not null，并且给出一个默认值。 4. 尽量少的使用一些大的类型，比如：text类型 如果非用不可的情况下，最好把这些字段单独提出来，存在一张附加表之中，一方面增加了主表的查询效率，另一方面在需要的时候对附加表进行这种大数据的查询。 使用int类型来存储时间，利用FROM_UNIXTIME（）和UNIX_TIMESTAMP（）两个函数来进行转换。 如 FROM_UNIXTIME(1443922330，‘%Y-%m-%d’); 得到一个格式化的

【问题现象】 线上mysql数据库爆出一个慢查询，DBA观察发现， 查询时服务器IO飙升，IO占用率达到100%， 执行时间长达7s左右 。 SQL语句如下： SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROM gm_game g LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ; 【问题分析】 使用explain查看执行计划，结果如下： 这条sql语句的问题其实还是比较明显的： 查询了大量数据(包括数据条数、以及g.* )，然后使用临时表order by，但最终又只返回了20条数据。 DBA观察到的IO高，是因为sql语句生成了一个巨大的临时表，内存放不下，于是全部拷贝到磁盘，导致IO飙升。 【优化方案】 优化的总体思路是拆分sql

性能优化之mysql优化 可以从几个方面进行优化 硬件 系统配置 数据库表结构 SQL索引 成本从高到底，效果从低到高。 如何发现有问题的SQL？ 使用mysql慢查询日志对有效率问题的sql进行监控。 show variables like 'slow_query.log'; set global slow_query_log_file='/home/mysql/sql_log/mysql-slow.log';//日志存放的位置 set global log_queries_not_using_indexes=on;//是否把没有使索引的sql记录到慢查询日志中 set global long_query_time=1;//超过多少秒的查询记录到日志当中 如何分析SQL查询 演示数据库说明： 使用mysql提供的sakila数据库，可以通过以下url获取这个演示数据库 http://dev.mysql.com/doc/index-other.html sakila数据库的表结构信息可以通过以下网站查看： http://dev.mysql.com/doc/sakila/en/sakila-installation.html 准备工作结束。 来源： oschina 链接： https://my.oschina.net/u/1423209/blog/511805