mysql性能优化精品PPT课件
合集下载
MySQL调优技术分享PPT
多表查询优化建议
二、连接和子查询的比较 开发效率：子查询将一个SQL拆分成多个SQL进行查询，连接查询只查询一个SQL，把业务逻辑放到
SQL中，提高了开发效率。 查询效率： （子查询优于关联查询）：联合查询相较于单查询减少了通信次数，降低了通讯上时间的消耗；
由于数据库存在缓存机制，所以开启MYSQL查询的话，单查询的可重用性较高，缓存效率比联合查询也 会更高。
多表查询优化建议
一、连接（关联查询）： 基础介绍： 1、内连接：两个表中同时满足某条件的数据记录组合，两个表的交集；关键词 inner join 或 join 2、外连接：（左外连接和右外连接还有全连接） ①：左外连接：A的全集以及A和B的交集；关键词：left join ②：右外连接：B的全集以及A和B的交集；关键词：right join ③：全连接：A与B的并集。 ④：交叉连接：A与B的笛卡尔乘积。关键词：cross join 内部实现原理： 嵌套循环关联，先确定一端，再进行匹配。
04
拓展
MYSQL缓存机制
一、MYSQL缓存机制
原理：MySQL的Query_Cache:将查询语句和返回的结果集使用KV形式存在内存中；当发起一个 查询请求，先对该SQL进行权限验证，接着就通过Query Cache来查找结果。它不需要经过Optimizer模块 进行执行计划的分析优化，更不需要发生同任何存储引擎的交互，减少了大量的磁盘IO和CPU运算，所以 有时候效率非常高。
索引下推
2020
演示完毕 感谢观看
锁竞争：联合查询查询速度比单个查询要慢，所以联合查询会增加锁的竞争关系。 （关联查询优于子查询）：MYSQL查询优化器更好读懂关联查询，所以更快预算出更好的查询
路径。
MySQL数据库设计、优化幻灯片
• 不要同时指定字符集（character set）和校验集（collect set），避免出现和默认对应关系不一致
Value ''
CHAR(4) Storage Required VARCHAR(4) Storage Required
''
4 bytes
''
1 byte
'ab' 'abcd' 'abcdefgh'
规范
字段规范
• char(10) VS varchar(10)
• 尽可能不使用text/blob类型
• 存储字符型数据时，尽可能先压缩或者序列化
• 注意字符集问题，server=>database(trigger、stored procedure、event
scheduler)=>table=>column
规范
命名规范
• 涉及系统目录、文件、数据库、表、字段名 • 强烈建议只用小写字符、数字、下划线组合 • 命名长度不超过32个字符 • 不使用select、show、update等保留字 • 全英文或全中文，言之有意，不要半洋半中 • 临时用加上 tmp/temp 前缀/后缀 • 统计表加上 stat/statistic 前缀/后缀 • 历史归档加上完整日期，例如：20130802
规范
SQL规范
• 过滤用户提交SQL，防止注入 • 杜绝 like ‘%xxx%’，不用/少用 like ‘xxx%’ • 不用/少用子查询，改造成连接（JOIN） • 不用/少用FOR UPDATE、LOCK IN SHARE MODE，防止锁范围扩大化 • SQL中不用/少用函数，可能造成额外开销或者导致无法使用索引 • 分页SQL采用内连接（INNER JOIN）实现，更高效
MySQL 的性能调优
MySQL 的性能调优MySQL 数据库是互联网公司使用最为频繁的数据库之一，不仅仅因为它开源免费，MySQL 卓越的性能、稳定的服务以及活跃的社区都成就了它的核心竞争力。
应用服务与数据库的交互主要是通过SQL 语句来实现的。
在开发初期，我们更加关注的是使用SQL 实现业务功能，然而系统上线后，随着生产环境数据的快速增长，之前写的很多SQL 语句就开始暴露出性能问题。
在这个阶段中，我们应该尽量避免一些慢SQL 语句的实现。
但话说回来，SQL 语句慢的原因千千万，除了一些常规的慢SQL 语句可以直接规避，其它的一味去规避也不是办法，我们还要学会如何去分析、定位到其根本原因，并总结一些常用的SQL 调优方法，以备不时之需。
慢SQL 语句的几种常见诱因1. 无索引、索引失效导致慢查询如果在一张几千万数据的表中以一个没有索引的列作为查询条件，大部分情况下查询会非常耗时，这种查询毫无疑问是一个慢SQL 查询。
所以对于大数据量的查询，我们需要建立适合的索引来优化查询。
虽然我们很多时候建立了索引，但在一些特定的场景下，索引还有可能会失效，所以索引失效也是导致慢查询的主要原因之一。
2. 锁等待我们常用的存储引擎有InnoDB 和MyISAM，前者支持行锁和表锁，后者只支持表锁。
如果数据库操作是基于表锁实现的，试想下，如果一张订单表在更新时，需要锁住整张表，那么其它大量数据库操作（包括查询）都将处于等待状态，这将严重影响到系统的并发性能。
这时，InnoDB 存储引擎支持的行锁更适合高并发场景。
但在使用InnoDB 存储引擎时，我们要特别注意行锁升级为表锁的可能。
在批量更新操作时，行锁就很可能会升级为表锁。
MySQL 认为如果对一张表使用大量行锁，会导致事务执行效率下降，从而可能造成其它事务长时间锁等待和更多的锁冲突问题发生，致使性能严重下降，所以MySQL 会将行锁升级为表锁。
还有，行锁是基于索引加的锁，如果我们在更新操作时，条件索引失效，那么行锁也会升级为表锁。
MySql优化精品PPT课件
3、解决问题：HOW – 升级硬、软件
不同RAID级别 & 不同磁100
89
80 68
60
40
20
0
raid 5(4)
raid 5(6)
raid 1+0(4)
raid 1+0(6)
3、解决问题：HOW – 升级硬、软件
FW 升级前后 8G内存拷贝38G大文件耗时对比
status/processlist
show [global] status 重点关注key hit ratio, qcache hit ratio, lock, slow
query, innodb buffer hit ratio, innodb data/log write/read
show processlist 重点关注一些异常状态的查询，或者耗时很长的查询
Linux下的MySQL调优
1
需求来源：WHY
2
分析问题：WHERE
3
解决问题：HOW
4
总结
3、解决问题：HOW
硬件
软件
MySQL自身 程序，架构
3、解决问题：HOW – 升级硬、软件
通常硬件是优化的最佳入口，主要是CPU、内存、 磁盘、网络，尤其是IO上的提升 应用服务器和服务器在一个高速的局域网内 通常，新版本的效率不如旧版本，但是可以利用 新版本的新功能来从另一方面得到性能上的提升 编译优化，采用静态编译等 使用更稳定高效的内核 使用合适的文件系统，推荐使用xfs(高级文件系 统实现者指南)
88 86 84 82 80 78
76 74 72 70
86.493 FW升级前
76.0777 FW升级后
MySQL优化技巧与实例.ppt
MySQL数据库的大体介绍
举例： 惠普，摩托罗拉，索尼，腾讯，， YouTube等大企业、大网站所使用
日本第三大，世界排名42的网站 mixi.jp 的数 据库技术资料 Database: MySQL Server Database Size: 836 GB (Diaries) 400 Million Rows per Table
观察在有建立tl_userid索引和没建立tl_userid索引下 的执行时间
使用索引
索引的代价 减慢了插入、删除的速度，同时也减慢了更新被索引 的数据列中的值的速度
索引会花费磁盘空间，多个索引相应地花费更多的磁盘空间
使用索引
选择索引字段
用于索引的最好的备选数据列是那些出现在WHERE子句、 join子句、ORDER BY或GROUP BY子句中的列。仅仅出现 在SELECT关键字后面的输出数据列列表中的数据列不是很好 的备选列，比如： SELECT col_a <- 不是备选列 FROM table1 LEFT JOIN table2 ON table1.col_b = table2.col_c <- 备选列 WHERE col_d = value; <- 备选列
MySQL优化技巧与实例
MySQL数据库的大体介绍 优化思想 控制SELECT行为 使用索引 查询优化器 优化字段属性设置 使用连接来代替子查询 优化查询语句 使用外键
MySQL数据库的大体介绍
MySQL是一个高性能、多线程、多用户、建立 在客户-服务器结构上的RDBMS，专门为速度 和稳定性而设计。 开源，免费 对大容量的数据有很好的支持 大多数中小型网站的首选 目前版本到6.0，主流为5.x，国内还有不少用 4.x。 目前流行的LAMP架构的一部分。
MySql语句优化ppt课件
索引的优缺点
优点 1.可以通过建立唯一索引或者主键索引,保证数据库表中每一行数据的唯一性. 2.建立索引可以大大提高检索的数据,以及减少表的检索行数 3.在表连接的连接条件 可以加速表与表直接的相连 4.在分组和排序字句进行数据检索,可以减少查询时间中 分组 和 排序时所消耗的时间(数据库的记录 会重新排序) 5.建立索引,在查询中使用索引 可以提高性能
THANKS
如上图，是一颗b+树，浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所 示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块， P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、 15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项， 如17、35并不真实存在于数据表中。 ###b+树的查找过程 如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定 29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘 块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2 指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。 真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大 的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。
8.尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，其次对 于查询来说，在一个相对较小的字段内搜索效率显然要高些 9.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字 段 10.尽量避免向客户端返回大数据量
mysql教程PPT(无水印)
MySQL的应用场景
网站和Web应用
MySQL是许多流行的网站和Web应用 的数据库首选。
数据仓库和分析
MySQL可以用于构建数据仓库和进 行数据分析，支持大数据处理和数据
挖掘。
企业应用
MySQL适用于各种企业级应用，如 客户关系管理（CRM）、人力资源管 理和财务管理等。
游戏开发
MySQL可以用于游戏开发中的后端 数据库管理，支持游戏数据存储和查 询。
04 安全性
随着网络安全问题的日益突出， MySQL将加强数据加密、身份验 证等方面的安全措施，确保用户 数据的安全与隐私。
THANKS
日志记录
01
启用并配置MySQL的日志记录功能，记录用户的活动和数据库
的更改。
安全审计
02
定期审查和分析日志记录，发现潜在的安全威胁和异常行为。
日志轮换和管理
03
设置日志轮换计划，定期清理旧的日志文件，确保日志文件不
会无限制增长。
06
MySQL与其他数据库的比较 和未来发展
与其他数据库的比较
Oracle
表的创建和管理
创建表
使用`CREATE TABLE`语 句创建一个新的表。
删除表
使用`DROP TABLE`语 句删除一个存在的表。
修改表
使用`ALTER TABLE`语 句修改一个存在的表。
数据插入、查询、更新和删除
数据插入
使用`INSERT INTO`语句将数据 插入到表中。
数据查询
使用`SELECT`语句查询表中的 数据。
数据库的备份和恢复
备份
备份是创建数据库副本的过程，用于防止数据丢失和灾难恢复。MySQL支持多 种备份方法，如全备份、增量备份和差异备份。
MySQL数据库应用与开发 第12章 MySQL性能优化
Logo
优化MySQL服务器
3. 通过MySQL控制台进行性能优化 ❖数据库管理人员可以使用show status或
show variables like语句来查询MySQL数据库的性能 参数，然后用set语句对系统变量进行赋值。 ❖使查用询va主lue要参数性时能常用参的数几个统计参数。这些常用参数介绍如下。 （CU1op）ntinm利eec：t用ioMnsyshS：oQ连wL服接s务tMa器tyuS的sQ语上L服线句务时查器间的询；次M数y；SQL数据库的性能 S语low法_q形ue式rie如s：下慢查：询的次数；
❖ 在实际工作中，数据的查询优化可以有效地提高 MySQL数据库的性能。一个成功的数据库应用系统的 开发，在查询优化方面一定会付出资源。对查询优化 的处理，不仅会影响到数据库的工作效率，而且会给 社会带来较高的效益。
❖ 本章将学习优化MySQL服务器、优化数据表、优化查 询的方法和技巧。
Hale Waihona Puke Logo优化MySQL服务器
MySQL
数据库应用与开发
2021/9/22
1
Logo
第12章 MySQL性能优化
内容提要
1 优化MySQL服务器 2 优化查询 3 优化数据库结构 4 查询高速缓存
2021/9/22
2
Logo
❖ 优化性能是通过某些高效的方法提高MySQL数据库的 性能，其目的是为了使MySQL数据库运行速度更快、 占用的磁盘空间更小。性能优化包括优化查询速度、 优化更新速度、优化MySQL服务器等。优化MySQL数 据库是数据库管理员的必备技能。
show variables like ‘value’;
其中，value参数是常用的几个统计参数如下。 key_buffer_size：表示索引缓存的大小。 table_cache：表示同时打开的表的个数。 query_cache_size：表示查询缓冲区的大小。 Query_cache_type：表示查询缓存区的开启状态。0表示关闭，1表示开启。 Sort_buffer_size：排序缓存区的大小，这个值越大，排序就越快。 Innodb_buffer_pool_size：表示InnoDB类型的表和索引的最大缓存。这个 值越大，查询的速度就会越快。但是，这个值太大了也会影响操作系统的性能。
MySQL中高并发热点更新性能优化演示课件-精选.ppt
精品课件
12
精品课件
3
MySQL层的现象
• 绝大部分线程在更新商品库存量
– update t set 库存量 -1 where ...
• 正常的查询和更新的RT也剧增
• 祈求业务降级以让DB抗过去
精品课件
4
问题的本质原因
• InnoDB层行锁机制
– 每行更新请求都会创建一个记录锁对象 – 成功加锁则执行，失败则被挂起 – 相同的记录锁被HASH到同一桶中
– 同一桶中线程串行，不同桶中线程则并行 – 同一桶中轮询重试加锁 – 重试超时强制进入，避免调度上的死锁
精品课件
9
加锁逻辑图
精品课件
10
优化效果
• Default: • Deadlock Disabled: • Hot Rows Control:
50 250 10500
• 测试
精品课件
11
QA
MySQL中高并发热点更新 性能优化
希羽
精品课件
1
大纲
• 典型的业务场景及问题 • MySQL层的现象 • 问题的本质原因 • 曾经的尝试方法 • 问题的难点 • 瞬间热点更新检测模型 • 瞬间热点更新线程调度 • 优化效果
精品课件
2
典型的业务场景及问题Fra bibliotekMySQL的性能瞬间急剧下降，TPS 1W --> 200
精品课件
5
曾经的尝试方法
• 2011年 禁掉死锁检测
– 死锁检测开销巨大，占~80% CPU 资源 – facebook任然保留这样的做法 – 2011年开启挺过双11
• 2012年 严格并发控制
– 严格控制InnoDB层并发数 – 挺过双12 – 双12晚高峰的小插曲
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
MySQL优化
目录索引
MySQL优化方式 MySQL技巧分享 MySQL函数
MySQL优化方式
MySQL优化方式
系统优化：硬件、架构 服务优化 应用优化
系统优化
使用好的硬件，更快的硬盘、大内存、多核CPU，专业的存 储服务器（NAS、SAN）
设计合理架构，如果 MySQL 访问频繁，考虑 Master/Slave 读写分离；数据库分表、数据库切片（分布式），也考虑使 用相应缓存服务帮助 MySQL 缓解访问压力
选项
max_connections query_cache_size sort_buffer_size
record_buffer table_cache
缺省值
100 0 (不打开）M 16M
16M 512
说明
MySQL服务器同时处理的数据库连接的最大数量
查询缓存区的最大长度，按照当前需求，一倍一倍 增加，本选项比较重要
每个线程的排序缓存大小，一般按照内存可以设置 为2M以上，推荐是16M，该选项对排序order by， group by起作用
每个进行一个顺序扫描的线程为其扫描的每张表分 配这个大小的一个缓冲区，可以设置为2M以上
为所有线程打开表的数量。增加该值能增加mysqld 要求的文件描述符的数量。MySQL对每个唯一打开 的表需要2个文件描述符。
8M
128M 0 256M
innodb_log_buffer_size
128K
8M
说明
InnoDB使用一个缓冲池来保存索引和原始数据, 这 里你设置越大,你在存取表里面数据时所需要的磁盘 I/O越少，一般是内存的一半，不超过2G，否则系 统会崩溃，这个参数非常重要
InnoDB用来保存 metadata 信息, 如果内存是4G， 最好本值超过200M
服务优化
MySQL配置原则
配置合理的MySQL服务器，尽量在应用本身达到一个MySQL最 合理的使用
针对 MyISAM 或 InnoDB 不同引擎进行不同定制性配置 针对不同的应用情况进行合理配置 针对 f 进行配置，后面设置是针对内存为2G的服务器
进行的合理设置
服务优化
公共选项
类型的字段建立索引 需要的时候建立联合索引，但是要注意查询SQL语句的编写 谨慎建立 unique 类型的索引（唯一索引）
大文本字段不建立为索引，如果要对大文本字段进行检索， 可以考虑全文索引 频繁更新的列不适合建立索引 一般建议每条记录最好有一个能快速定位的独一无二定位的 唯一标示（索引） 不要过度索引，单表建立的索引不要超过5个，否则更新索 引将很耗时
样一来，用这个字段来做一些选项列表变得相当的完美 。
不要使用无法加索引的类型作为关键字段，比如 text类型 为了避免联表查询，有时候可以适当的数据冗余，比如
邮箱、姓名这些不容易更改的数据 选择合适的表引擎，有时候 MyISAM 适合，有时候
InnoDB适合 为保证查询性能，最好每个表都建立有 auto_increment
服务优化
MyISAM 选项
选项 key_buffer_size read_buffer_size
缺省值 推荐值 8M 256M 128K 16M
myisam_sort_buffer_si 16M 128M ze
说明
用来存放索引区块的缓存值, 建议128M以上 ，不要大于内存的30%
用来做MyISAM表全表扫描的缓冲大小. 为 从数据表顺序读取数据的读操作保留的缓存 区的长度
字段， 建立合适的数据库索引 最好给每个字段都设定 default 值
应用优化
索引建立原则(一)
一般针对数据分散的关键字进行建立索引，比如ID、QQ， 像性别、状态值等等建立索引没有意义
字段唯一，最少，不可为null 对大数据量表建立聚集索引，避免更新操作带来的碎片。 尽量使用短索引，一般对int、char/varchar、date/time 等
的update，Delete SQL性能。 5.Decimal 类型字段不要单独建立为索引，但覆盖索引可以包
含这些字段。 6.只有建立索引以后，表内的行才按照特地的顺序存储，按照
需要可以是asc或desc方式。 7.如果索引由多个字段组成将最用来查询过滤的字段放在前面
用来缓冲日志数据的缓冲区的大小. 推荐是8M，官 方推荐该值小于16M，最好是 1M-8M 之间
应用优化
应用优化方式
设计合理的数据表结构 对数据表建立合适有效的数据库索引 数据查询：编写简洁高效的SQL语句
应用优化
表结构设计原则
选择合适的数据类型：如果能够定长尽量定长
使用 ENUM 而不是 VARCHAR,ENUM类型是非常快和紧凑的， 在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这
应用优化
索引建立原则(二)
1. order by 字句中的字段，where 子句中字段，最常用的sql 语句中字段，应建立索引。
2.唯一性约束，系统将默认为改字段建立索引。 3.对于只是做查询用的数据库索引越多越好，但对于在线实时
系统建议控制在5个以内。 4.索引不仅能提高查询SQL性能，同时也可以提高带where字句
0 代表日志只大约每秒写入日志文件并且日志文件刷新到磁 盘; 1 为执行完没执行一条SQL马上commit; 2 代表日志写 入日志文件在每次提交后,但是日志文件只有大约每秒才会刷 新到磁盘上. 对速度影响比较大，同时也关系数据完整性
在日志组中每个日志文件的大小, 一般是 innodb_buffer_pool_size的25%，官方推荐是 innodb_buffer_pool_size 的 40-50%, 设置大一点来 避免在日志文件覆写上不必要的缓冲池刷新行为
设置,恢复,修改表的时候使用的缓冲大小， 值不要设的太大
服务优化
InnoDB 选项
选项
innodb_buffer_pool_size
缺省值 推荐值
32M
1G
innodb_additional_mem_po 2M ol_size
innodb_flush_log_at_trx_co 1 mmit
innodb_log_
目录索引
MySQL优化方式 MySQL技巧分享 MySQL函数
MySQL优化方式
MySQL优化方式
系统优化：硬件、架构 服务优化 应用优化
系统优化
使用好的硬件，更快的硬盘、大内存、多核CPU，专业的存 储服务器（NAS、SAN）
设计合理架构，如果 MySQL 访问频繁，考虑 Master/Slave 读写分离；数据库分表、数据库切片（分布式），也考虑使 用相应缓存服务帮助 MySQL 缓解访问压力
选项
max_connections query_cache_size sort_buffer_size
record_buffer table_cache
缺省值
100 0 (不打开）M 16M
16M 512
说明
MySQL服务器同时处理的数据库连接的最大数量
查询缓存区的最大长度，按照当前需求，一倍一倍 增加，本选项比较重要
每个线程的排序缓存大小，一般按照内存可以设置 为2M以上，推荐是16M，该选项对排序order by， group by起作用
每个进行一个顺序扫描的线程为其扫描的每张表分 配这个大小的一个缓冲区，可以设置为2M以上
为所有线程打开表的数量。增加该值能增加mysqld 要求的文件描述符的数量。MySQL对每个唯一打开 的表需要2个文件描述符。
8M
128M 0 256M
innodb_log_buffer_size
128K
8M
说明
InnoDB使用一个缓冲池来保存索引和原始数据, 这 里你设置越大,你在存取表里面数据时所需要的磁盘 I/O越少，一般是内存的一半，不超过2G，否则系 统会崩溃，这个参数非常重要
InnoDB用来保存 metadata 信息, 如果内存是4G， 最好本值超过200M
服务优化
MySQL配置原则
配置合理的MySQL服务器，尽量在应用本身达到一个MySQL最 合理的使用
针对 MyISAM 或 InnoDB 不同引擎进行不同定制性配置 针对不同的应用情况进行合理配置 针对 f 进行配置，后面设置是针对内存为2G的服务器
进行的合理设置
服务优化
公共选项
类型的字段建立索引 需要的时候建立联合索引，但是要注意查询SQL语句的编写 谨慎建立 unique 类型的索引（唯一索引）
大文本字段不建立为索引，如果要对大文本字段进行检索， 可以考虑全文索引 频繁更新的列不适合建立索引 一般建议每条记录最好有一个能快速定位的独一无二定位的 唯一标示（索引） 不要过度索引，单表建立的索引不要超过5个，否则更新索 引将很耗时
样一来，用这个字段来做一些选项列表变得相当的完美 。
不要使用无法加索引的类型作为关键字段，比如 text类型 为了避免联表查询，有时候可以适当的数据冗余，比如
邮箱、姓名这些不容易更改的数据 选择合适的表引擎，有时候 MyISAM 适合，有时候
InnoDB适合 为保证查询性能，最好每个表都建立有 auto_increment
服务优化
MyISAM 选项
选项 key_buffer_size read_buffer_size
缺省值 推荐值 8M 256M 128K 16M
myisam_sort_buffer_si 16M 128M ze
说明
用来存放索引区块的缓存值, 建议128M以上 ，不要大于内存的30%
用来做MyISAM表全表扫描的缓冲大小. 为 从数据表顺序读取数据的读操作保留的缓存 区的长度
字段， 建立合适的数据库索引 最好给每个字段都设定 default 值
应用优化
索引建立原则(一)
一般针对数据分散的关键字进行建立索引，比如ID、QQ， 像性别、状态值等等建立索引没有意义
字段唯一，最少，不可为null 对大数据量表建立聚集索引，避免更新操作带来的碎片。 尽量使用短索引，一般对int、char/varchar、date/time 等
的update，Delete SQL性能。 5.Decimal 类型字段不要单独建立为索引，但覆盖索引可以包
含这些字段。 6.只有建立索引以后，表内的行才按照特地的顺序存储，按照
需要可以是asc或desc方式。 7.如果索引由多个字段组成将最用来查询过滤的字段放在前面
用来缓冲日志数据的缓冲区的大小. 推荐是8M，官 方推荐该值小于16M，最好是 1M-8M 之间
应用优化
应用优化方式
设计合理的数据表结构 对数据表建立合适有效的数据库索引 数据查询：编写简洁高效的SQL语句
应用优化
表结构设计原则
选择合适的数据类型：如果能够定长尽量定长
使用 ENUM 而不是 VARCHAR,ENUM类型是非常快和紧凑的， 在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这
应用优化
索引建立原则(二)
1. order by 字句中的字段，where 子句中字段，最常用的sql 语句中字段，应建立索引。
2.唯一性约束，系统将默认为改字段建立索引。 3.对于只是做查询用的数据库索引越多越好，但对于在线实时
系统建议控制在5个以内。 4.索引不仅能提高查询SQL性能，同时也可以提高带where字句
0 代表日志只大约每秒写入日志文件并且日志文件刷新到磁 盘; 1 为执行完没执行一条SQL马上commit; 2 代表日志写 入日志文件在每次提交后,但是日志文件只有大约每秒才会刷 新到磁盘上. 对速度影响比较大，同时也关系数据完整性
在日志组中每个日志文件的大小, 一般是 innodb_buffer_pool_size的25%，官方推荐是 innodb_buffer_pool_size 的 40-50%, 设置大一点来 避免在日志文件覆写上不必要的缓冲池刷新行为
设置,恢复,修改表的时候使用的缓冲大小， 值不要设的太大
服务优化
InnoDB 选项
选项
innodb_buffer_pool_size
缺省值 推荐值
32M
1G
innodb_additional_mem_po 2M ol_size
innodb_flush_log_at_trx_co 1 mmit
innodb_log_