请您谈下数据库调优，指的是哪方面？
读写[写: update/delete/add]分离
存储过程 [模块化编程，可以提高速度]
对 mysql 配置优化 [配置最大并发数 my.ini, 调整缓存大小 ]
mysql 服务器硬件升级
定时的去清除不需要的数据,定时进行碎片整理(MyISAM)
对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：
① 数
据库设计
② sql 语句优化
③ 数据库参数配置
④ 恰当的硬件资源和操作系统
此外，使用适当的存储过程，也能提升性能。
这个顺序也表现了这四个工作对性能影响的大小
数据库表设计
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF 是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足 1NF)
第二范式：2NF 是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF 是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。
但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。
冗余的结论：
1—n 冗余应当发生在 1 这一方.
SQL 优化的一般步骤
通过 show status 命令了解各种 SQL 的执行频率。
定位执行效率较低的 SQL 语句-（重点 select）
通过 explain 分析低效率的 SQL
确定问题并采取相应的优化措施
SQL 语句优化-定位慢查询
默认情况下，mysql 认为 10 秒才是一个慢查询.
SQL 语句优化-explain 分析问题
Explain select * from emp where ename=“wsrcla”
会产生如下信息：
select_type:表示查询的类型。
table:输出结果集的表
type:表示表的连接类型
possible_keys:表示查询时，可能使用的索引
key:表示实际使用的索引
key_len:索引字段的长度
rows:扫描出的行数(估算的行数)
Extra:执行情况的描述和说明
建立适当的索引
说起提高数据库性能，索引是最物美价廉的东西了。不用加内存，不用改程序，不用调 sql，只要执行个正确的’create index’，查询速度就可能提高百倍千倍，这可真有诱惑力。可是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的 I/O。
btree 类型的索引，就是使用的二分查找法，肯定快啊，算法复杂度是 log2N，也就是说 16 条数据查 4 次，32 条数据查 5 次，64 条数据查 6 次….依次类推。
使用索引跟没使用索引的区别，就跟我们使用新华字典查字，一个是根据拼音或者笔画查找，一个是从头到尾一页一页翻。
索引的代价
1、磁盘占用
2、对 dml(update delete insert)语句的效率影响
btree 方式检索，算法复杂度： log2N 次数
简述 mysql 四种索引的区别
PRIMARY 索引 =》在主键上自动创建
UNIQUE 索引=> 只要是 UNiQUE 就是 Unique 索引.(只能在字段内容不重复的情况下，才能创建唯一索引)
INDEX 索引=>就是普通索引
FULLTEXT => 只在 MYISAM 存储引擎支持, 目的是全文索引，在内容系统中用的多， 在全英文网站用多(英文词独立). 中文数据不常用，意义不大，国内全文索引通常使用 sphinx 来完成,全文索引只能在 char varchar text 字段创建.
选择合适的存储引擎
MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性要求不是很高。其优势是访问的速度快。
InnoDB：Mysql5.6 默认的 MySQL 存储引擎，提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比 MyISAM，写的处理效率差一些并且会占用更多的磁盘空间。
Memory：数据存在内存中，服务重启时，数据丢失
MyISAM： 在插入数据时，默认放在最后. ,删除数据后，空间不回收.(不支持事务和外键)
如果选用小原则:
1.如果追求速度，不在乎数据是否一直保存，也不考虑事务，请选择 memory 比如存放用户在线状态.
2.如果表的数据要持久保存，应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性要求不是很高。选用 MyISAM
3.如果需要数据持久保存，并提供了具有提交、回滚和崩溃恢复能力的事务安全,请选用 Innodb
对表进行水平划分
如果一个表的记录数太多了，比如上千万条，而且需要经常检索，那么我们就有必要化整为零了。如果我拆成 100 个表，那么每个表只有 10 万条记录。当然这需要数据在逻辑上可以划分。一个好的划分依据，有利于程序的简单实现，也可以充分利用水平分表的优势。比如系统界面上只提供按月查询的功能，那么把表按月拆分成 12 个，每个查询只查询一个表就够了。如果非要按照地域来分，即使把表拆的再小，查询还是要联合所有表来查，还不如不拆了。所以一个好的拆分依据是 最重要的。关键字：UNION
对表进行垂直划分
评论