数据库优化

如图，从低成本高收益开始。

1、sql及索引

1、sql语句优化。
80%的问题都是sql本身的问题。先分析sql扫描的行数是否最小；如果是关联查询，关联的行数是否最小；如果是子查询，子查询的行数是否最小。
2、常用的查询条件是否走索引。
大部分查询慢，确保查询走索引就会优化。如果不是非常用字段，就要想法将查询目标行数缩减到最小量，再加入非索引条件。
多个字段过滤时，可以考虑联合索引。
更多索引的方式有空追加完善。
3、explain sql分析。
如果个人无法快速分析sql，可以借助explain工具。oracle的方式不同，此处以mysql为例。
explain select xx from aa where w1=xx and w2=xx
查看分析结果，每个执行计划是否走索引，不走索引就会显示all，行数也会比较多。

2、数据库设计

首先，数据库表结构需要基本满足三个基本范式。为什么说基本满足呢？完全满足有时候并不是能够高效的实现数据库的使用和存储。可以适量的冗余，但不能过度冗余。
适量冗余一般为code,name都存储，增加审计或保留字段。
过度冗余是将多个对象都存入一个table，或者将对象之间的一对多、多对一、多对对关系存入表。

其次，数据库的字段类型尽量使用最小的数据类型和长度。
数据库的主键尽量使用自增或雪花算法。
如果有大文本，尽量使用nosql或其他方式。

如果涉及到大数据量，可以分库分表。或者历史数据归档。

3、数据库配置

（1） innodb_flush_log_at_trx_commit
默认为1，这是数据库的事务提交设置参数，可选值如下：
0:日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。
1：在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新。
2：在每个提交，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新。对日志文件每秒刷新一次。
频繁写入可以设置为2。
（2) temp_table_size,heap_table_size根据实际业务情况设置大于需要写入的数据量占用空间大小才行。
（3) max_allowed_packet=256M,net_buffer_length=16M，set autocommit=0备份和恢复时如果设置好这三个参数,可以让你的备份恢复速度飞起来哦！
（4)innodb_data_file_path=ibdata1:1G;ibdata2:64M:autoextend很显然表空间后面的autoextend就是让表空间自动扩展，不够默认情况下只有10M，而在大批量数据写入的场景，不妨把这个参数调大；让表空间增长时一次尽可能分配更多的表空间，避免在大批量写入时频繁的进行文件扩容
（5)innodb_log_file_size,innodb_log_files_in_group,innodb_log_buffer_size设置事务日志的大小，日志组数，以及日志缓存。默认值很小，innodb_log_file_size默认值才几十M，innodb_log_files_in_group默认为2。innodb_log_file_size可以设置为内存1/4,其他按需求调大。
（6) innodb_buffer_pool_size设置MySQL Innodb的可用缓存大小。理论上最大可以设置为服务器总内存的80%. 设置越大的值，当然比设置小的值的写入性能更好。比如上面的参数innodb_log_file_size就是参考innodb_buffer_pool_size的大小来设置的。
（7)innodb_thread_concurrency=16官方建议是CPU核数的两倍左右最合适。
（8)write_buffer_size控制单个会话单次写入的缓存大小，默认值4K左右，一般可以不用调整。大批量写入可以尝试调整为2M。
（9) innodb_buffer_pool_instance默认为1，大批量写入可以调大该参数。
（10) bin_log二进制日志，数据库备份还原时关闭。

4、硬件

分析磁盘 cpu，使用固态硬盘，高带宽等