數據庫優化
一、數據庫硬件優化（選型）
1.一般數據庫選擇
1.真實的硬件，物理機
2.雲產品ECS，自己搭建數據庫
3.雲數據庫（RDS、DRDS）
2.數據庫類型
1.OLTP 在線事務處理系統
支持大量並發用戶定期添加和修改數據。
反映隨時變化的單位狀態，但不保存其歷史記錄。
包含大量數據，其中包括用於驗證事務的大量數據。
可以進行優化以對事務活動做出響應。
提供用於支持單位日常運營的技術基礎結構。
個別事務能夠很快地完成，並且只需訪問相對較少的數據。
實時性要求高。
交易一般是確定的，所以OLTP是對確定性的數據進行存取。(比如存取款都有一個特定的金額)
並發性要求高並且嚴格的要求事務的完整、安全性。
2.OLAP 數據倉庫，數據處理，數據展示（使用nosql更適合）
ROLAP
MOLAP
HOLAP
3.硬件選型
1）CPU選型
1.IO密集型：線上系統，OLTP主要是IO密集型的業務，高並發（OLTP），E系列（至強），主頻相對低，核心數量多
2.CPU密集型：數據分析數據處理，OLAP，cpu密集型的，需要CPU高計算能力（OLAP，不需要很高的並發，計算只用一個用戶就可以了），I系列的（IBM），主頻很高，核心少 （打游戲一般選擇CPU密集型）
2）內存選擇
1.建議2-3倍cpu核心數量 （ECC）
2.內存越大它使用越多，浪費越多，命中率越低
3）磁盤選擇
1.SATA-III
2.SAS
3.Fc
4.SSD（sata）
pci-e 級別
Flash 級別
4）存儲選擇（一般大型企業）
5）網絡選擇
1.硬件買好的（單卡單口，網卡有很多個口，選擇單口的，性能更好）
一般可以插4塊卡，兩個內網兩個外網，避免一塊出現問題就掛掉
2.網卡綁定（bonding），交換機堆疊
意思就像負載均衡，將兩塊網卡邏輯綁定，一個網卡綁定一個交換機，如果做了網卡綁定，交換機也一定要做堆疊
綁定方式：負載均衡模式，主備模式
4.操作系統優化
1）Swap調整
echo 0 >/proc/sys/vm/swappiness的內容改成0（臨時），
/etc/sysctl.conf 上添加 vm.swappiness=0（永久）
sysctl -p
這個參數決定了Linux是傾向於使用swap，還是傾向於釋放文件系統cache。在內存緊張的情況下，數值越低越傾向於釋放文件系統cache。
當然，這個參數只能減少使用swap的概率，並不能避免Linux使用swap。
2）IO調度策略
centos 7 默認是deadline
cat /sys/block/sda/queue/scheduler
#臨時修改為deadline(centos6)
echo deadline > /sys/block/sda/queue/scheduler
vi /boot/grub/grub.conf
更改到如下內容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet
5.應用端優化
1. 減少爛SQL：不走索引，復雜邏輯，切割大事務（插入100萬條數據可以拆成100條插入一次）
2. 避免業務邏輯錯誤
3. 說白了就是使用數據庫時，操作標准一些
二、創建數據庫
1.創建一個庫一個表，並插入100萬數據
#創建庫
create database opt
use opt
#創建表
create table test(id int(11),num int(11),k1 char(2),k2 char(4),dt timestamp not null);
#插入100萬數據
delimiter //
create procedure rand_data(in num int)
begin
declare str char(62) default 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890';
declare str2 char(2);
declare str4 char(4);
declare i int default 0;
while i<num do
set str2=concat(substring(str,1+floor(rand()*61),1),substring(str,1+floor(rand()*61),1));
set str4=concat(substring(str,1+floor(rand()*61),2),substring(str,1+floor(rand()*61),2));
set i=i+1;
insert into test values(i,floor(rand()*num),str2,str4,now());
end while;
end;
//
delimiter;
mysql> call rand_data(1000000);
2.查看數據可用性
mysql -uroot -p123
select count(*) from opt.test;
3.進行壓力測試
mysqlslap --defaults-file=/etc/my.cnf \
--concurrency=100 --iterations=1 --create-schema='opt' \
--query="select * from opt.test where num='505037'" engine=innodb \
--number-of-queries=20000 -uroot -p123 -verbose
三、數據庫參數優化
1.Max_connections
1.簡介
Mysql的最大連接數，如果服務器的並發請求量比較大，可以調高這個值，當然這是要建立在機器能夠支撐的情況下，因為如果連接數越來越多，mysql會為每個連接提供緩沖區，就會開銷的越多的內存，所以需要適當的調整該值，不能隨便去提高設值。
2.查看方式
mysql> show variables like 'max_connections';
mysql> select @@max_connections;
#查看已經使用多少
mysql> show status like 'Max_used_connections';
3.一般配置
vim /etc/my.cnf
Max_connections=1024
4.補充:
1.開啟數據庫時,我們可以臨時設置一個比較大的測試值
2.觀察show status like 'Max_used_connections';變化
3.如果max_used_connections跟max_connections相同,那么就是max_connections設置過低或者超過服務器的負載上限了，低於10%則設置過大.
#額外指標
IOPS 每秒支持的IO
connections 連接數
TPS 每秒最多允許的事務
QPS 每秒最多的查詢量
2.back_log
1.簡介：
mysql能暫存的連接數量，當主要mysql線程在一個很短時間內得到非常多的連接請求時候它就會起作用，如果mysql的連接數據達到max_connections時候，新來的請求將會被存在堆棧中，等待某一連接釋放資源，該推棧的數量及back_log，如果等待連接的數量超過back_log，將不被授予連接資源。
back_log值指出在mysql暫時停止回答新請求之前的短時間內有多少個請求可以被存在推棧中，只有如果期望在一個短時間內有很多連接的時候需要增加它
2.查看方式
mysql> show variables like '%back_log%';
mysql> select @@back_log;
#查看有沒有等待的，如發現大量的待連接進程時，就需要加大back_log或者加大max_connections的值
mysql> show full processlist
3.配置方式
vim /etc/my.cnf
back_log=1024
3.wait_timeout和interactive_timeout
1.簡介
wait_timeout：指的是mysql在關閉一個非交互的連接之前所要等待的秒數
interactive_timeout：指的是mysql在關閉一個交互的連接之前所需要等待的秒數，比如我們在終端上進行mysql管理，使用的即使交互的連接，這時候，如果沒有操作的時間超過了interactive_timeout設置的時間就會自動的斷開，默認的是28800，可調優為7200。
wait_timeout:如果設置太小，那么連接關閉的就很快，從而使一些持久的連接不起作用
#interactive_timeout類似跳板機，過了多久沒操作就會踢掉你，需要重新連接
2.查看方式
mysql> select @@wait_timeout;
mysql> select @@interactive_timeout;
#默認的都是是28800，可調優為7200。
3.配置方式（配置這個可以減輕內存的壓力）
wait_timeout=60
interactive_timeout=1200
#如果設置太大，容易造成連接打開時間過長，在show processlist時候，能看到很多的連接 ，一般希望wait_timeout盡可能低
#長連接的應用，為了不去反復的回收和分配資源，降低額外的開銷。一般我們會將wait_timeout設定比較小，interactive_timeout要和應用開發人員溝通長鏈接的應用是否很多。如果他需要長鏈接，那么這個值可以不需要調整。
4.key_buffer_size
1.簡介
key_buffer_size指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度
1)此參數與myisam表的索引有關
select table_name,engine from information_schema.tables where engine='myisam';
2)臨時表的創建有關（多表鏈接、子查詢中、union）
在有以上查詢語句出現的時候，需要創建臨時表，用完之后會被丟棄
臨時表有兩種創建方式：
內存中------->key_buffer_size
磁盤上------->ibdata1(5.6)
ibtmp1 (5.7）
2.查看方式
mysql> show variables like "%key_buffer_size%";
#默認是8M
#查看有多少在走索引，上面的總數，下面的是走磁盤的
mysql> show status like "key_read%";
3.查看臨時表創建
mysql> show status like "created_tmp%";
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 10 | #創建在磁盤的臨時表
| Created_tmp_files | 6 | #一共臨時文件的數量
| Created_tmp_tables | 70 | #創建在內存中的臨時表
+-------------------------+-------+
#通常地，我們習慣以磁盤建表百分比或者已各自的一個時段內的差額計算，來判斷基於內存的臨時表利用率。所以，我們會比較關注 Created_tmp_disk_tables 是否過多，從而認定當前服務器運行狀況的優劣。
#忽略mysqldump備份時導致的大量使用磁盤表
4.配置方式
key_buffer_size=64M
5.query_cache_size
[rml_read_more]：
1.簡介：
查詢緩存簡稱QC，使用查詢緩沖，mysql將查詢結果存放在緩沖區中，今后對於同樣的select語句（區分大小寫）,將直接從緩沖區中讀取結果。
SQL層：
select * from t1 where name=:NAME;
select * from t1 where name=:NAME;
1）查詢完結果之后，會對SQL語句進行hash運算，得出hash值,我們把他稱之為SQL_ID
2）會將存儲引擎返回的結果+SQL_ID存儲到緩
2.查看方式
mysql> show variables like "%query_cache_size%";
#查看是否開啟
mysql> show variables like "query_cache%";
+------------------------------+---------+
| Variable_name | Value |
+------------------------------+---------+
| query_cache_limit | 1048576 | #超過此大小的查詢將不緩存
| query_cache_min_res_unit | 4096 | #緩存塊的最小大小，太小的話會生成很多內存碎片
| query_cache_size | 1048576 | #查詢緩存大小
| query_cache_type | OFF | #緩存類型，是否開啟
| query_cache_wlock_invalidate | OFF | #查詢的表被鎖，也可以走緩存查詢數據
+------------------------------+---------+
3.配置多大根據誰呢
mysql> show status like "%Qcache%";
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Qcache_free_blocks | 1 | #緩存中相鄰內存塊的個數，內存碎片
| Qcache_free_memory | 1031360 | #Query Cache 中目前剩余的內存大小
| Qcache_hits | 0 | #表示有多少次命中緩存，數字越大，緩存效果越理想
| Qcache_inserts | 0 | #沒有命中，新插入的數據
| Qcache_lowmem_prunes | 0 | #多少條Query因為內存不足而被清除出QueryCache
| Qcache_not_cached | 2002 | #不適合進行緩存的查詢的數量，通常是由於這些查詢不是 SELECT 語句或者用了now()之類的函數
| Qcache_queries_in_cache | 0 | #當前Query Cache 中cache 的Query 數量
| Qcache_total_blocks | 1 | #當前Query Cache 中的block 數量
+-------------------------+---------+
#求命中率：
Qcache_hits / (Qcache_inserts+Qcache_not_cached+Qcache_hits)
如果出現hits比例過低，其實就可以關閉查詢緩存了。使用redis專門緩存數據
#判斷內存夠不夠
Qcache_free_memory + Qcache_lowmem_prunes
4.一般配置
修改/etc/my.cnf,配置完后的部分文件如下：
query_cache_size=128M
query_cache_type=1
6.max_connect_errors
1.簡介
max_connect_errors是一個mysql中與安全有關的計數器值，它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼等情況，當超過指定次數，mysql服務器將禁止host的連接請求，直到mysql服務器重啟或通過flush hosts命令清空此host的相關信息 max_connect_errors的值與性能並無太大關系。
2.查看方式
mysql> show variables like "%connect_error%";
3.配置方式
修改/etc/my.cnf文件，在[mysqld]下面添加如下內容
max_connect_errors=2000
7.sort_buffer_size
1.簡介：
每個需要進行排序的線程分配該大小的一個緩沖區。增加這值加速
ORDER BY、GROUP BY、distinct、union
#Sort_Buffer_Size並不是越大越好，由於是connection級的參數，過大的設置+高並發可能會耗盡系統內存資源。列如：500個連接將會消耗500*sort_buffer_size（2M）=1G內存
2.查看方式
mysql> show variables like "%sort_buffer_size%";
3.配置方法
修改/etc/my.cnf文件，在[mysqld]下面添加如下：
sort_buffer_size=1M
8.max_allowed_packet
1.簡介：
mysql根據配置文件會限制，server接受的數據包大小。所有程序都是數據包的形式訪問數據庫的
2.查看方式
mysql> show variables like '%max_allowed_packet%';
3.配置依據：
有時候大的插入和更新會受max_allowed_packet參數限制，導致寫入或者更新失敗，更大值是1GB，必須設置1024的倍數，最好的方式就是讓開發修改，不要讓數據包超過限制
4.一般配置
max_allowed_packet=32M
9.join_buffer_size
1.簡介
每個使用join的線程分配該大小的一個緩沖區。增加這值加速
select a.name,b.name from a join b on a.id=b.id where xxxx
用於表間關聯緩存的大小，和sort_buffer_size一樣，該參數對應的分配內存也是每個連接獨享。
盡量在SQL與方面進行優化，效果較為明顯。
優化的方法：在on條件列加索引，至少應當是有普通索引
2.查看方式
mysql> show variables like "%join_buffer_size%";
3.一般配置
join_buffer_size=2M
10.thread_cache_size
1.簡介
服務器線程緩存，這個值表示可以重新利用保存在緩存中線程的數量,當斷開連接時,那么客戶端的線程將被放到緩存中以響應下一個客戶而不是銷毀(前提是緩存數未達上限),如果線程重新被請求，那么請求將從緩存中讀取,如果緩存中是空的或者是新的請求，那么這個線程將被重新創建,如果有很多新的線程，增加這個值可以改善系統性能.
#每個連接數據庫都會分配一部分資源，如果退出資源會釋放，下次再來新的又會分配，頻繁的有用戶訪問和退出，會對服務器線程造成很大的壓力，配置這個可以理解為長鏈接，他的值不是大小，而是數量
2.查看方式
mysql> show variables like "%thread_cache_size%";
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 9 | #個數而不是大小
+-------------------+-------+
3.配置要根據實際情況
#查看試圖連接到MySQL(不管是否連接成功)的連接數
mysql> show status like 'threads_%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 8 |
| Threads_connected | 2 |
| Threads_created | 4783 |
| Threads_running | 1 |
+-------------------+-------+
4 rows in set (0.00 sec)
Threads_cached :代表當前此時此刻線程緩存中有多少空閑線程。
Threads_connected:代表當前已建立連接的數量，因為一個連接就需要一個線程，所以也可以看成當前被使用的線程數。
Threads_created:代表從最近一次服務啟動，沒有走緩存創建線程的數量，如果發現Threads_created值過大的話，表明MySQL服務器一直在創建線程，這也是比較耗資源，可以適當增加配置文件中thread_cache_size值。
Threads_running :代表當前激活的（非睡眠狀態）線程數。並不是代表正在使用的線程數，有時候連接已建立，但是連接處於sleep狀態。
4.一般配置（內存壓力過大，不適合設置太大）
(3)配置方法：
thread_cache_size=32
#整理：
Threads_created ：一般在架構設計階段，會設置一個測試值，做壓力測試。
結合zabbix監控，看一段時間內此狀態的變化。
如果在一段時間內，Threads_created趨於平穩，說明對應參數設定是OK。
如果一直陡峭的增長，或者出現大量峰值，那么繼續增加此值的大小，在系統資源夠用的情況下（內存）
11.innodb_buffer_pool_size
1.簡介
對於InnoDB表來說，innodb_buffer_pool_size的作用就相當於key_buffer_size對於MyISAM表的作用一樣。
簡單來說，就是pool-size可以緩存索引和行數據，值越大，IO讀寫就越少，如果單純的做數據庫服務，該參數可以設置到電腦物理內存的80%
#設置要根據自己的實際情況來設置，如果設置的值不在合理的范圍內，並不是設置越大越好，可能設置的數值太大體現不出優化效果，反而造成系統的swap空間被占用，導致操作系統變慢，降低sql查詢性能。
2.查看方式（默認128M）
mysql> show variables like "%innodb_buffer_pool_size%";
3.配置方法
innodb_buffer_pool_size=2048M
12.innodb_flush_log_at_trx_commit （面試可能會問）
1.簡介
主要控制了innodb將log buffer中的數據寫入日志文件並flush磁盤的時間點，取值分別為0、1、2三個。
0，表示當事務提交時，不做日志寫入操作，而是每秒鍾將log buffer中的數據寫入日志文件並flush磁盤一次；
1，則在每秒鍾或是每次事物的提交都會引起日志文件寫入、flush磁盤的操作，確保了事務的ACID；
2，每次事務提交引起寫入日志文件的動作,但每秒鍾完成一次flush磁盤操作。
#當innodb_flush_log_at_trx_commit被 設置為0，日志緩沖每秒一次地被寫到日志文件，並且對日志文件做到磁盤操作的刷新，但是在一個事務提交不做任何操作。當這個值為1（默認值）之時，在每個事務提交時，日志緩沖被寫到日志文件，對日志文件做到磁盤操作的刷新。當設置為2之時，在每個提交，日志緩沖被寫到文件，但不對日志文件做到磁盤操作的刷新。盡管如此，在對日志文件的刷新在值為2的情況也每秒發生一次。我們必須注意到，因為進程安排問題，每秒一次的刷新不是100%保證每秒都發生。你可以通過設置這個值不為1來獲得較好的性能，但隨之你會在一次崩潰中損失二分之一價值的事務。如果你設置這個值為0，那么任何mysqld進程的崩潰會刪除崩潰前最后一秒的事務，如果你設置這個值為2，那么只有操作系統崩潰或掉電才會刪除最后一秒的事務。盡管如此，InnoDB的崩潰恢復不受影響，而且因為這樣崩潰恢復開始作用而不考慮這個值。注意，許多操作系統和一些磁盤硬件會欺騙刷新到磁盤操作。盡管刷新沒有進行，你可以告訴mysqld刷新已經進行。即使設置這個值為1，事務的持久程度不被保證，且在最壞情況下掉電甚至會破壞InnoDB數據庫。在SCSI磁盤控制器中，或在磁盤自身中，使用有后備電池的磁盤緩存會加速文件刷新並且使得操作更安全。你也可以試着使用Unix命令hdparm來在硬件緩存中禁止磁盤寫緩存，或使用其它一些對硬件提供商專用的命令。這個選項的默認值是1。
2.配置依據
實際測試發現，該值對插入數據的速度影響非常大，設置為2時插入10000條記錄只需要2秒，設置為0時只需要1秒，而設置為1時則需要229秒。因此，MySQL手冊也建議盡量將插入操作合並成一個事務，這樣可以大幅提高速度。根據MySQL官方文檔，在允許丟失最近部分事務的危險的前提下，可以把該值設為0或2。
3.查看方式
mysql> show variables like "%innodb_flush_log_at_trx_commit%";
4.配置方法
innodb_flush_log_at_trx_commit=1
雙1標准中的一個1
5.雙一標准另一個1
sync_binlog
sync_binlog 的默認值是0，像操作系統刷其他文件的機制一樣，MySQL不會同步到磁盤中去而是依賴操作系統來刷新binary log。sync_binlog控制數據庫的binlog刷到磁盤上去
默認，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系統自己控制它的緩存的刷新。這時候的性能是最好的，但是風險也是最大的。因為一旦系統Crash，在binlog_cache中的所有binlog信息都會被丟失。
如果sync_binlog>0，表示每sync_binlog次事務提交，MySQL調用文件系統的刷新操作將緩存刷下去。最安全的就是sync_binlog=1了，表示每次事務提交，MySQL都會把binlog刷下去，是最安全但是性能損耗最大的設置。這樣的話，在數據庫所在的主機操作系統損壞或者突然掉電的情況下，系統才有可能丟失1個事務的數據。但是binlog雖然是順序IO，但是設置sync_binlog=1，多個事務同時提交，同樣很大的影響MySQL和IO性能。雖然可以通過group commit的補丁緩解，但是刷新的頻率過高對IO的影響也非常大。對於高並發事務的系統來說，“sync_binlog”設置為0和設置為1的系統寫入性能差距可能高達5倍甚至更多。
13.innodb_thread_concurrency
1.簡介
此參數用來設置innodb線程的並發數量，默認值為0表示不限制。數據庫屬於單進程多線程，怎么保證CPU使用的
一般線程小於64，設置innodb_thread_concurrency 為0，如果工作負載一直很高，建議設置innodb_thread_concurrency=128，逐漸降低測試一個最優的值，一般查看CPU使用率去配置，如果CPU使用率很平均，那么不需要調優，如果不平均，可以配置innodb_thread_concurrency由低逐漸加大來測試
設置標准：
1）當前系統cpu使用情況，均不均勻
top
2）當前的連接數，有沒有達到頂峰
show status like 'threads_%';
show processlist;
設置方法:
1）看top ,觀察每個cpu的各自的負載情況
2）發現不平均,先設置參數為cpu個數,然后不斷增加(一倍)這個數值
3）一直觀察top狀態,直到達到比較均勻時,說明已經到位了.
2.查看方式
mysql> show variables like "%innodb_thread_concurrency%";
3.配置方式
innodb_thread_concurrency=8
在官方doc上，對於innodb_thread_concurrency的使用，也給出了一些建議，如下：
如果一個工作負載中，並發用戶線程的數量小於64，建議設置innodb_thread_concurrency=0；
如果工作負載一直較為嚴重甚至偶爾達到頂峰，建議先設置innodb_thread_concurrency=128，
並通過不斷的降低這個參數，96, 80, 64等等，直到發現能夠提供最佳性能的線程數，
例如，假設系統通常有40到50個用戶，但定期的數量增加至60，70，甚至200。你會發現，
性能在80個並發用戶設置時表現穩定，如果高於這個數，性能反而下降。在這種情況下，
建議設置innodb_thread_concurrency參數為80，以避免影響性能。
如果你不希望InnoDB使用的虛擬CPU數量比用戶線程使用的虛擬CPU更多（比如20個虛擬CPU），
建議通過設置innodb_thread_concurrency 參數為這個值（也可能更低，這取決於性能體現），
如果你的目標是將MySQL與其他應用隔離，你可以l考慮綁定mysqld進程到專有的虛擬CPU。
但是需 要注意的是，這種綁定，在myslqd進程一直不是很忙的情況下，可能會導致非最優的硬件使用率。在這種情況下，
你可能會設置mysqld進程綁定的虛擬 CPU，允許其他應用程序使用虛擬CPU的一部分或全部。
在某些情況下，最佳的innodb_thread_concurrency參數設置可以比虛擬CPU的數量小。
定期檢測和分析系統，負載量、用戶數或者工作環境的改變可能都需要對innodb_thread_concurrency參數的設置進行調整。
14.innodb_log_buffer_size
1.簡介
此參數確定些日志文件所用的內存大小，以M為單位。緩沖區更大能提高性能，對於較大的事務，可以增大緩存大小。
設定依據：
1）大事務
2）多事務：事務並發提交時，如果值太小會影響效率，所有的事務都在等待
2.查看方式
mysql> show variables like "%innodb_log_buffer_size%";
3.配置方式
innodb_log_buffer_size=128M
15.innodb_log_file_size
1.簡介
設置磁盤文件的大小
設置 ib_logfile0 ib_logfile1 大小
此參數確定數據日志文件的大小，以M為單位，更大的設置可以提高性能.
2.查看方式
mysql> show variables like '%innodb_log_file_size%';
3.配置
innodb_log_file_size=128M
16.innodb_log_files_in_group
1.簡介
為提高性能，MySQL可以以循環方式將日志文件寫到多個文件。推薦設置為3
2.查看方法
mysql> show variables like '%innodb_log_files_in_group%';
3.設置
innodb_log_files_in_group=3
17.read_buffer_size
1.簡介
MySql讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區，MySql會為它分配一段內存緩沖區。如果對表的順序掃描請求非常頻繁，並且你認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。和 sort_buffer_size一樣，該參數對應的分配內存也是每個連接獨享
2.查看方式
mysql> show variables like '%read_buffer_size%';
3.配置
read_buffer_size=1M
18.read_rnd_buffer_size
1.簡介
MySql的隨機讀（查詢操作）緩沖區大小。當按任意順序讀取行時(例如，按照排序順序)，將分配一個隨機讀緩存區。進行排序查詢時，MySql會首先掃描一遍該緩沖，以避免磁盤搜索，提高查詢速度，如果需要排序大量數據，可適當調高該值。但MySql會為每個客戶連接發放該緩沖空間，所以應盡量適當設置該值，以避免內存開銷過大。
注：順序讀是指根據索引的葉節點數據就能順序地讀取所需要的行數據。隨機讀是指一般需要根據輔助索引葉節點中的主鍵尋找實際行數據，而輔助索引和主鍵所在的數據段不同，因此訪問方式是隨機的。
2.查看方式
mysql> show variables like '%read_rnd_buffer_size%';
3.配置
read_rnd_buffer_size=1M
19.bulk_insert_buffer_size = 8M
1.簡介
批量插入數據緩存大小，可以有效提高插入效率，默認為8M
2.查看方式
mysql> show variables like '%bulk_insert_buffer_size%';
3.一般配置
bulk_insert_buffer_size=8M
20.binary log
log-bin=/data/mysql-bin
binlog_cache_size = 2M //為每個session 分配的內存，在事務過程中用來存儲二進制日志的緩存, 提高記錄bin-log的效率。沒有什么大事務，dml也不是很頻繁的情況下可以設置小一點，如果事務大而且多，dml操作也頻繁，則可以適當的調大一點。前者建議是--1M，后者建議是：即 2--4M
max_binlog_cache_size = 8M //表示的是binlog 能夠使用的最大cache 內存大小
max_binlog_size= 512M //指定binlog日志文件的大小，如果當前的日志大小達到max_binlog_size，還會自動創建新的二進制日志。你不能將該變量設置為大於1GB或小於4096字節。默認值是1GB。在導入大容量的sql文件時，建議關閉sql_log_bin，否則硬盤扛不住，而且建議定期做刪除。
expire_logs_days = 7 //定義了mysql清除過期日志的時間。
二進制日志自動刪除的天數。默認值為0,表示“沒有自動刪除”。
log-bin=/data/mysql-bin
binlog_format=row
sync_binlog=1
雙1標准(基於安全的控制)：
sync_binlog=1 什么時候刷新binlog到磁盤，每次事務commit
innodb_flush_log_at_trx_commit=1
set sql_log_bin=0;
#查看語句執行數量
show status like 'com_%';
21.安全參數
Innodb_flush_method=(O_DIRECT, fdatasync)
1.fdatasync
1)在數據頁需要持久化時，首先將數據寫入OS buffer中，然后由os決定什么時候寫入磁盤
2)在redo buffuer需要持久化時，首先將數據寫入OS buffer中，然后由os決定什么時候寫入磁盤，但如果innodb_flush_log_at_trx_commit=1的話，日志還是直接每次commit直接寫入磁盤
2.Innodb_flush_method=O_DIRECT
1)在數據頁需要持久化時，直接寫入磁盤
2)在redo buffuer需要持久化時，首先將數據寫入OS buffer中，然后由os決定什么時候寫入磁盤，但如果innodb_flush_log_at_trx_commit=1的話，日志還是直接每次commit直接寫入磁盤
1.數據庫基於安全的話
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
2.數據庫基於性能的話
innodb_flush_log_at_trx_commit=0
innodb_flush_method=fdatasync
22.最終數據庫配置
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
log-error=mysql.err
log_bin=mysql-bin
binlog_format=row
skip-name-resolve
server-id=1
log-slave-updates=1
relay_log_purge=0
max_connections=1024
back_log=128
wait_timeout=60
interactive_timeout=7200
key_buffer_size=16M
query_cache_size=64M
query_cache_type=1
query_cache_limit=50M
max_connect_errors=20
sort_buffer_size=2M
max_allowed_packet=32M
join_buffer_size=2M
thread_cache_size=200
innodb_buffer_pool_size=1024M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=32M
innodb_log_file_size=128M
innodb_log_files_in_group=3
binlog_cache_size=2M
max_binlog_cache_size=8M
max_binlog_size=512M
expire_logs_days=7
read_buffer_size=2M
read_rnd_buffer_size=2M
bulk_insert_buffer_size=8M
[client]
socket=/tmp/mysql.sock