『壹』 幾個常用的Mysql性能測試工具
1、mysqlslap
安裝：簡單，裝了mysql就有了
作用：模擬並發測試資料庫性能。
優點：簡單，容易使用。
不足：不能指定生成的數據規模，測試過程不清楚針對十萬級還是百萬級數據做的測試，感覺不太適合做綜合測試，比較適合針對既有資料庫，對單個sql進行優化的測試。
使用方法：
可以使用mysqlslap --help來顯示使用方法：
Default options are read from the following files in the given order:
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
--concurrency代表並發數量，多個可以用逗號隔開，concurrency=10,50,100, 並發連接線程數分別是10、50、100個並發。
--engines代表要測試的引擎，可以有多個，用分隔符隔開。
--iterations代表要運行這些測試多少次。
--auto-generate-sql 代表用系統自己生成的SQL腳本來測試。
--auto-generate-sql-load-type 代表要測試的是讀還是寫還是兩者混合的（read,write,update,mixed）
--number-of-queries 代表總共要運行多少次查詢。每個客戶運行的查詢數量可以用查詢總數/並發數來計算。
--debug-info 代表要額外輸出CPU以及內存的相關信息。
--number-int-cols ：創建測試表的 int 型欄位數量
--auto-generate-sql-add-autoincrement : 代表對生成的表自動添加auto_increment列，從5.1.18版本開始
--number-char-cols 創建測試表的 char 型欄位數量。
--create-schema 測試的schema，MySQL中schema也就是database。
--query 使用自定義腳本執行測試，例如可以調用自定義的一個存儲過程或者sql語句來執行測試。
--only-print 如果只想列印看看SQL語句是什麼，可以用這個選項。
mysqlslap -umysql -p123 --concurrency=100 --iterations=1 --auto-generate-sql --auto-generate-sql-add-autoincrement --auto-generate-sql-load-type=mixed --engine=myisam --number-of-queries=10 --debug-info
或：
指定資料庫和sql語句:
mysqlslap -h192.168.3.18 -P4040 --concurrency=100 --iterations=1 --create-schema='test' --query='select * from test;' --number-of-queries=10 --debug-info -umysql -p123
要是看到底做了什麼可以加上：--only-print
Benchmark
Average number of seconds to run all queries: 25.225 seconds
Minimum number of seconds to run all queries: 25.225 seconds
Maximum number of seconds to run all queries: 25.225 seconds
Number of clients running queries: 100
Average number of queries per client: 0
以上表明100個客戶端同時運行要25秒
2、sysbench
安裝：
可以從http://sourceforge.net/projects/sysbench/ 下載
tar zxf sysbench-0.4.12.tar.gz
cd sysbench-0.4.12
./autogen.sh
./configure && make && make install
strip /usr/local/bin/sysbench
安裝時候可能會報錯，後來發現個好文 http://blog.csdn.net/icelemon1314/article/details/7004955 怕以後找不到，也貼過來吧
1.如果mysql不是默認路徑安裝，那麼需要通過指定--with-mysql-includes和--with-mysql-libs參數來載入mysql安裝路徑
2.如果報錯：
../libtool: line 838: X--tag=CC: command not found
../libtool: line 871: libtool: ignoring unknown tag : command not found
../libtool: line 838: X--mode=link: command not found
../libtool: line 1004: *** Warning: inferring the mode of operation is deprecated.: command not found
../libtool: line 1005: *** Future versions of Libtool will require --mode=MODE be specified.: command not found
../libtool: line 2231: X-g: command not found
../libtool: line 2231: X-O2: command not found
那麼執行下根目錄的：autogen.sh文件，然後重新configure && make && make install
3.如果報錯：
sysbench: error while loading shared libraries: libmysqlclient.so.18: cannot open shared object file: No such file or directory
那麼執行下：
n -s /usr/local/mysql5.5/mysql/lib/libmysqlclient.so.18 /usr/lib64/
4.如果執行autogen.sh時，報如下錯誤：
./autogen.sh: line 3: aclocal: command not found
那麼需要安裝一個軟體：
yum install automake
然後需要增加一個參數：查找： AC_PROG_LIBTOOL 將其注釋，然後增加AC_PROG_RANLIB
作用：模擬並發,可以執行CPU/內存/線程/IO/資料庫等方面的性能測試。資料庫目前支持MySQL/Oracle/PostgreSQL
優點：可以指定測試數據的規模，可以單獨測試讀、寫的性能，也可以測試讀寫混合的性能。
不足：測試的時候，由於網路原因，測試的非常慢，但是最終給的結果卻很好，並發支持很高，所以給我的感覺是並不太准確。當然也可能我沒搞明白原理
使用方法：
准備數據
sysbench --test=oltp --mysql-table-engine=myisam --oltp-table-size=400000 --mysql-db=dbtest2 --mysql-user=root --mysql-host=192.168.1.101 --mysql-password=pwd prepare
執行測試
sysbench --num-threads=100 --max-requests=4000 --test=oltp --mysql-table-engine=innodb --oltp-table-size=400000 --mysql-db=dbtest1 --mysql-user=root --mysql-host=192.168.1.101 --mysql-password=pwd run
sysbench 0.4.12: multi-threaded system evaluation benchmark
No DB drivers specified, using mysql
Running the test with following options:
Number of threads: 100
Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Maximum number of requests for OLTP test is limited to 4000
Threads started!
Done.
OLTP test statistics:
queries performed:
read: 56014
write: 20005
other: 8002
total: 84021
transactions: 4001 (259.14 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 76019 (4923.75 per sec.)
other operations: 8002 (518.29 per sec.)
Test execution summary:
total time: 15.4393s
total number of events: 4001
total time taken by event execution: 1504.7744
per-request statistics:
min: 33.45ms
avg: 376.10ms
max: 861.53ms
approx. 95 percentile: 505.65ms
Threads fairness:
events (avg/stddev): 40.0100/0.67
execution time (avg/stddev): 15.0477/0.22
3、tpcc-mysql
安裝：
如果從原網站上下載源碼比較麻煩，需要工具、注冊、生成證書等。這里提供一個下載包http://blog.chinaunix.net/blog/downLoad/fileid/8532.html
export C_INCLUDE_PATH=/usr/include/mysql
export PATH=/usr/bin:$PATH
export LD_LIBRARY_PATH=/usr/lib/mysql
cd /tmp/tpcc/src
make
然後就會在 /tmp/tpcc-mysql 下生成 tpcc 命令行工具 tpcc_load 、 tpcc_start
作用：測試mysql資料庫的整體性能
優點：符合tpcc標准，有標準的方法，模擬真實的交易活動，結果比較可靠。
不足：不能單獨測試讀或者寫的性能，對於一些以查詢為主或者只寫的應用，就沒有這么大的意義了。
使用方法：
載入數據
創建庫
mysql>create database tpcc10;
創建表：
shell>mysql tpcc10 < create_table.sql
添加外鍵：
shell>mysql tpcc10 < add_fkey_idx.sql
載入數據:
1、單進程載入：
shell>./tpcc_load 192.168.11.172 tpcc10 root pwd 300
|主機||資料庫||用戶||密碼||warehouse|
2、並發載入：（推薦，但需要修改一下）
shell>./load.sh tpcc300 300
|資料庫||warehouse|
3、測試
./tpcc_start -h192.168.11.172 -d tpcc -u root -p 'pwd' -w 10 -c 10 -r 10 -l 60 -i 10 -f /mnt/hgfs/mysql/tpcc100_2013522.txt
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value '192.168.11.172'
option d with value 'tpcc'
option u with value 'root'
option p with value 'pwd'
option w with value '1'
option c with value '100'
option r with value '120'
option l with value '60'
option i with value '10'
option f with value '/mnt/hgfs/mysql/tpcc100_2013522.txt'
<Parameters>
[server]: 192.168.11.172
[port]: 3306
[DBname]: tpcc
[user]: root
[pass]: pwd
[warehouse]: 1
[connection]: 100
[rampup]: 120 (sec.)
[measure]: 60 (sec.)
RAMP-UP TIME.(120 sec.)
MEASURING START.
『貳』 如何測試sqlserver性能
1、打開sql server studio management
2、打開"工具"-"sql server profiler"
3、點擊連接
4、點擊運行
5、可以看到捕捉到的一些訪問資料庫的事件，其中有讀寫，點用cpu，持續時間等信息可以參考
6、點擊某個事件，可以查看具體執行了什麼sql腳本，進一步分析相關邏輯
『叄』 國內重要的 Go 語言項目：TiDB 3.0 GA，穩定性和性能大幅提升
TiDB 是 PingCAP 自主研發的開源分布式關系型資料庫，具備商業級資料庫的數據可靠性，可用性，安全性等特性，支持在線彈性水平擴展，兼容 MySQL 協議及生態，創新性實現 OLTP 及 OLAP 融合。
TiDB 3.0 版本顯著提升了大規模集群的穩定性，集群支持 150+ 存儲節點，300+TB 存儲容量長期穩定運行。易用性方面引入大量降低用戶運維成本的優化，包括引入 Information_Schema 中的多個實用系統視圖、EXPLAIN ANALYZE、SQL Trace 等。在性能方面，特別是 OLTP 性能方面，3.0 比 2.1 也有大幅提升，其中 TPC-C 性能提升約 4.5 倍，Sysbench 性能提升約 1.5 倍，OLAP 方面，TPC-H 50G Q15 因實現 View 可以執行，至此 TPC-H 22 個 Query 均可正常運行。新功能方面增加了窗口函數、視圖（實驗特性）、分區表、插件系統、悲觀鎖（實驗特性）。
截止本文發稿時 TiDB 已在 500+ 用戶的生產環境中長期穩定運行，涵蓋金融、保險、製造，互聯網， 游戲 等領域，涉及交易、數據中台、 歷史 庫等多個業務場景。不同業務場景對關系型資料庫的訴求可用 「百花齊放」來形容，但對關系資料庫最根本的訴求未發生任何變化，如數據可靠性，系統穩定性，可擴展性，安全性，易用性等。請跟隨我們的腳步梳理 TiDB 3.0 有什麼樣的驚喜。
3.0 與 2.1 版本相比，顯著提升了大規模集群的穩定性，支持單集群 150+ 存儲節點，300+TB 存儲容量長期穩定運行，主要的優化點如下：
1. 優化 Raft 副本之間的心跳機制，按照 Region 的活躍程度調整心跳頻率，減小冷數據對集群的負擔。
2. 熱點調度策略支持更多參數配置，採用更高優先順序，並提升熱點調度的准確性。
3. 優化 PD 調度流程，提供調度限流機制，提升系統穩定性。
4. 新增分布式 GC 功能，提升 GC 的性能，降低大集群 GC 時間，提升系統穩定性。
眾所周知，資料庫查詢計劃的穩定性對業務至關重要，TiDB 3.0 版本採用多種優化手段提升查詢計劃的穩定性，如下：
1. 新增 Fast Analyze 功能，提升收集統計信息的速度，降低集群資源的消耗及對業務的影響。
2. 新增 Incremental Analyze 功能，提升收集單調遞增的索引統計信息的速度，降低集群資源的消耗及對業務的影響。
3. 在 CM-Sketch 中新增 TopN 的統計信息，緩解 CM-Sketch 哈希沖突導致估算偏大，提升代價估算的准確性，提升查詢計劃的穩定性。
4. 引入 Skyline Pruning 框架，利用規則防止查詢計劃過度依賴統計信息，緩解因統計信息滯後導致選擇的查詢計劃不是最優的情況，提升查詢計劃的穩定性。
5. 新增 SQL Plan Management 功能，支持在查詢計劃不準確時手動綁定查詢計劃，提升查詢計劃的穩定性。
1. OLTP
3.0 與 2.1 版本相比 Sysbench 的 Point Select，Update Index，Update Non-Index 均提升約 1.5 倍，TPC-C 性能提升約 4.5 倍。主要的優化點如下：
1. TiDB 持續優化 SQL 執行器，包括：優化 NOT EXISTS 子查詢轉化為 Anti Semi Join，優化多表 Join 時 Join 順序選擇等。
2. 優化 Index Join 邏輯，擴大 Index Join 運算元的適用場景並提升代價估算的准確性。
3. TiKV 批量接收和發送消息功能，提升寫入密集的場景的 TPS 約 7%，讀密集的場景提升約 30%。
4. TiKV 優化內存管理，減少 Iterator Key Bound Option 的內存分配和拷貝，多個 Column Families 共享 block cache 提升 cache 命中率等手段大幅提升性能。
5. 引入 Titan 存儲引擎插件，提升 Value 值超過 1KB 時性能，緩解 RocksDB 寫放大問題，減少磁碟 IO 的佔用。
6. TiKV 新增多線程 Raftstore 和 Apply 功能，提升單節點內可擴展性，進而提升單節點內並發處理能力和資源利用率，降低延時，大幅提升集群寫入能力。
TiDB Lightning 性能與 2019 年年初相比提升 3 倍，從 100GB/h 提升到 300GB/h，即 28MB/s 提升到 85MB/s，優化點，如下：
1. 提升 SQL 轉化成 KV Pairs 的性能，減少不必要的開銷。
2. 提升單表導入性能，單表支持批量導入。
3. 提升 TiKV-Importer 導入數據性能，支持將數據和索引分別導入。
4. TiKV-Importer 支持上傳 SST 文件限速功能。
RBAC（Role-Based Access Control，基於角色的許可權訪問控制） 是商業系統中最常見的許可權管理技術之一，通過 RBAC 思想可以構建最簡單「用戶-角色-許可權」的訪問許可權控制模型。RBAC 中用戶與角色關聯，許可權與角色關聯，角色與許可權之間一般是多對多的關系，用戶通過成為什麼樣的角色獲取該角色所擁有的許可權，達到簡化許可權管理的目的，通過此版本的迭代 RBAC 功能開發完成。
IP 白名單功能（企業版特性） ：TiDB 提供基於 IP 白名單實現網路安全訪問控制，用戶可根據實際情況配置相關的訪問策略。
Audit log 功能（企業版特性） ：Audit log 記錄用戶對資料庫所執行的操作，通過記錄 Audit log 用戶可以對資料庫進行故障分析，行為分析，安全審計等，幫助用戶獲取數據執行情況。
加密存儲（企業版特性） ：TiDB 利用 RocksDB 自身加密功能，實現加密存儲的功能，保證所有寫入到磁碟的數據都經過加密，降低數據泄露的風險。
完善許可權語句的許可權檢查 ，新增 ANALYZE，USE，SET GLOBAL，SHOW PROCESSLIST 語句許可權檢查。
1. 新增 SQL 方式查詢慢查詢，豐富 TiDB 慢查詢日誌內容，如：Coprocessor 任務數，平均/最長/90% 執行/等待時間，執行/等待時間最長的 TiKV 地址，簡化慢查詢定位工作，提高排查慢查詢問題效率，提升產品易用性。
2. 新增系統配置項合法性檢查，優化系統監控項等，提升產品易用性。
3. 新增對 TableReader、IndexReader 和 IndexLookupReader 運算元內存使用情況統計信息，提高 Query 內存使用統計的准確性，提升處理內存消耗較大語句的效率。
4. 制定日誌規范，重構日誌系統，統一日誌格式，方便用戶理解日誌內容，有助於通過工具對日誌進行定量分析。
5. 新增 EXPLAIN ANALYZE 功能，提升SQL 調優的易用性。
6. 新增 SQL 語句 Trace 功能，方便排查問題。
7. 新增通過 unix_socket 方式連接資料庫。
8. 新增快速恢復被刪除表功能，當誤刪除數據時可通過此功能快速恢復數據。
TiDB 3.0 新增 TiFlash 組件，解決復雜分析及 HTAP 場景。TiFlash 是列式存儲系統，與行存儲系統實時同步，具備低延時，高性能，事務一致性讀等特性。 通過 Raft 協議從 TiKV 中實時同步行存數據並轉化成列存儲格式持久化到一組獨立的節點，解決行列混合存儲以及資源隔離性問題。TiFlash 可用作行存儲系統（TiKV）實時鏡像，實時鏡像可獨立於行存儲系統，將行存儲及列存儲從物理隔離開，提供完善的資源隔離方案，HTAP 場景最優推薦方案；亦可用作行存儲表的索引，配合行存儲對外提供智能的 OLAP 服務，提升約 10 倍復雜的混合查詢的性能。
TiFlash 目前處於 Beta 階段，計劃 2019 年 12 月 31 日之前 GA，歡迎大家申請試用。
未來我們會繼續投入到系統穩定性，易用性，性能，彈性擴展方面，向用戶提供極致的彈性伸縮能力，極致的性能體驗，極致的用戶體驗。
穩定性方面 V4.0 版本將繼續完善 V3.0 未 GA 的重大特性，例如：悲觀事務模型，View，Table Partition，Titan 行存儲引擎，TiFlash 列存儲引擎；引入近似物理備份恢復解決分布資料庫備份恢復難題；優化 PD 調度功能等。
性能方面 V4.0 版本將繼續優化事務處理流程，減少事務資源消耗，提升性能，例如：1PC，省去獲取 commit ts 操作等。
彈性擴展方面，PD 將提供彈性擴展所需的元信息供外部系統調用，外部系統可根據元信息及負載情況動態伸縮集群規模，達成節省成本的目標。
我們相信戰勝「未知」最好的武器就是社區的力量，基礎軟體需要堅定地走開源路線。截止發稿我們已經完成 41 篇源碼閱讀文章。TiDB 開源社區總計 265 位 Contributor，6 位 Committer，在這里我們對社區貢獻者表示由衷的感謝，希望更多志同道合的人能加入進來，也希望大家在 TiDB 這個開源社區能夠有所收獲。
TiDB 3.0 GA Release Notes： https://pingcap.com/docs-cn/v3.0/releases/3.0-ga/
『肆』 咋測試tidb自增id是不是唯一
咋測試tidb自增id是唯一。tidb的自增id只能保證唯一性，不保證自增性和連續性，也不支持在線添加列auto_increment屬性，tidb的主鍵索引和唯一索引的存儲方式相同，不支持全文索引、空間索引、僅支持utf8/utf8mb4/ascii/latin1/binary幾個字元集。
tidb的存儲能力
無限水平擴展是TiDB的一大特點，這里說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server負責處理SQL請求，隨著業務的增長，可以簡單的添加TiDB Server節點，提高整體的處理能力，提供更高的吞吐。
TiKV負責存儲數據，隨著數據量的增長，可以部署更多的TiKV Server節點解決數據Scale的問題。PD會在TiKV節點之間以Region為單位做調度，將部分數據遷移到新加的節點上。所以在業務的早期，可以只部署少量的服務實例（推薦至少部署3個TiKV，3個PD，2個TiDB），隨著業務量的增長，按照需求添加TiKV或者TiDB實例。
『伍』 如何測試mysql的性能和穩定性
有一些有用的工具可以測試MySQL 和基於MySQL 的系統的性能。這里將演示如何利用這些工具進行測試。
mysqlslap
mysqlslap可以模擬伺服器的負載，並輸出計時信息。它包含在MySQL 5.1 的發行包中，應該在MySQL 4.1或者更新的版本中都可以使用。測試時可以執行並發連接數，並指定SQL 語句（可以在命令行上執行，也可以把SQL 語句寫入到參數文件中）。如果沒有指定SQL 語句，mysqlslap 會自動生成查詢schema 的SELECT 語句。
MySQL Benchmark Suite （sql-bench）
在MySQL 的發行包中也提供了一款自己的基準測試套件，可以用於在不同資料庫伺服器上進行比較測試。它是單線程的，主要用於測試伺服器執行查詢的速度。結果會顯示哪種類型的操作在伺服器上執行得更快。
這個測試套件的主要好處是包含了大量預定義的測試，容易使用，所以可以很輕松地用於比較不同存儲引擎或者不同配置的性能測試。其也可以用於高層次測試，比較兩個伺服器的總體性能。當然也可以只執行預定義測試的子集（例如只測試UPDATE 的性能）。這些測試大部分是CPU 密集型的，但也有些短時間的測試需要大量的磁碟I/O 操作。
這個套件的最大缺點主要有：它是單用戶模式的，測試的數據集很小且用戶無法使用指定的數據，並且同一個測試多次運行的結果可能會相差很大。因為是單線程且串列執行的，所以無法測試多CPU 的能力，只能用於比較單CPU 伺服器的性能差別。使用這個套件測試資料庫伺服器還需要Perl 和BDB 的支持，相關文檔請參考.
Super Smack
Super Smack是一款用於MySQL 和PostgreSQL的基準測試工具，可以提供壓力測試和負載生成。這是一個復雜而強大的工具，可以模擬多用戶訪問，可以載入測試數據到資料庫，並支持使用隨機數據填充測試表。測試定義在"smack"文件中，smack 文件使用一種簡單的語法定義測試的客戶端、表、查詢等測試要素。
Database Test Suite
Database Test Suite 是由開源軟體開發實驗室（OSDL,Open Source DevelopmentLabs）設計的，發布在SourceForge 網站上，這是一款類似某些工業標准測試的測試工具集，例如由事務處理性能委員會（TPC,Transaction Processing Performance Council）制定的各種標准。特別值得一提的是，其中的dbt2 就是一款免費的TPC-C OLTP 測試工具（未認證）。之前本書作者經常使用該工具，不過現在已經使用自己研發的專用於MySQL 的測試工具替代了。
Percona's TPCC-MySQL Tool
我們開發了一個類似TPC-C 的基準測試工具集，其中有部分是專門為MySQL 測試開發的。在評估大壓力下MySQL 的一些行為時，我們經常會利用這個工具進行測試（簡單的測試，一般會採用sysbench 替代），在源碼庫中有一個簡單的文檔說明。
sysbench
sysbench是一款多線程系統壓測工具。它可以根據影響資料庫伺服器性能的各種因素來評估系統的性能。例如，可以用來測試文件I/O、操作系統調度器、內存分配和傳輸速度、POSIX 線程，以及資料庫伺服器等。sysbench 支持Lua 腳本語言，Lua 對於各種測試場景的設置可以非常靈活。sysbench 是我們非常喜歡的一種全能測試工具，支持MySQL、操作系統和硬體的硬體測試。（節選自《高性能MySQL》）
『陸』 mysql資料庫性能測試
我理解的是你希望了解mysql性能測試的方法：
其實常用的一般：
選取最適用的欄位屬性
MySQL可以很好的支持大數據量的存取，但是一般說來，資料庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中欄位的寬度設得盡可能小。例如，在定義郵政編碼這個欄位時，如果將其設置為CHAR(255),顯然給資料庫增加了不必要的空間，甚至使用VARCHAR這種類型也是多餘的，因為CHAR(6)就可以很好的完成任務了。同樣的，如果可以的話，我們應該使用MEDIUMINT而不是BIGIN來定義整型欄位。
另外一個提高效率的方法是在可能的情況下，應該盡量把欄位設置為NOT NULL，這樣在將來執行查詢的時候，資料庫不用去比較NULL值。
對於某些文本欄位，例如「省份」或者「性別」，我們可以將它們定義為ENUM類型。因為在MySQL中，ENUM類型被當作數值型數據來處理，而數值型數據被處理起來的速度要比文本類型快得多。這樣，我們又可以提高資料庫的性能。
2、使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。例如，我們要將客戶基本信息表中沒有任何訂單的客戶刪除掉，就可以利用子查詢先從銷售信息表中將所有發出訂單的客戶ID取出來，然後將結果傳遞給主查詢，如下所示：
DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，並且寫起來也很容易。但是，有些情況下，子查詢可以被更有效率的連接（JOIN）.. 替代。例如，假設我們要將所有沒有訂單記錄的用戶取出來，可以用下面這個查詢完成：
SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
如果使用連接（JOIN）.. 來完成這個查詢工作，速度將會快很多。尤其是當salesinfo表中對CustomerID建有索引的話，性能將會更好，查詢如下：
SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL
連接（JOIN）.. 之所以更有效率一些，是因為 MySQL不需要在內存中創建臨時表來完成這個邏輯上的需要兩個步驟的查詢工作。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL 從 4.0 的版本開始支持 UNION 查詢，它可以把需要使用臨時表的兩條或更多的 SELECT 查詢合並的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證資料庫整齊、高效。使用 UNION 來創建查詢的時候，我們只需要用 UNION作為關鍵字把多個 SELECT 語句連接起來就可以了，要注意的是所有 SELECT 語句中的欄位數目要想同。下面的例子就演示了一個使用 UNION的查詢。
SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM proct
4、事務
盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯合（UNION）來創建各種各樣的查詢，但不是所有的資料庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設想一下，要把某個數據同時插入兩個相關聯的表中，可能會出現這樣的情況：第一個表中成功更新後，資料庫突然出現意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數據的不完整，甚至會破壞資料庫中的數據。要避免這種情況，就應該使用事務，它的作用是：要麼語句塊中每條語句都操作成功，要麼都失敗。換句話說，就是可以保持資料庫中數據的一致性和完整性。事物以BEGIN 關鍵字開始，COMMIT關鍵字結束。在這之間的一條SQL操作失敗，那麼，ROLLBACK命令就可以把資料庫恢復到BEGIN開始之前的狀態。
BEGIN;
INSERT INTO salesinfo SET CustomerID=14;
UPDATE inventory SET Quantity=11
WHERE item='book';
COMMIT;
事務的另一個重要作用是當多個用戶同時使用相同的數據源時，它可以利用鎖定資料庫的方法來為用戶提供一種安全的訪問方式，這樣可以保證用戶的操作不被其它的用戶所干擾。
5、鎖定表
盡管事務是維護資料庫完整性的一個非常好的方法，但卻因為它的獨占性，有時會影響資料庫的性能，尤其是在很大的應用系統中。由於在事務執行的過程中，資料庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務結束。如果一個資料庫系統只有少數幾個用戶
來使用，事務造成的影響不會成為一個太大的問題；但假設有成千上萬的用戶同時訪問一個資料庫系統，例如訪問一個電子商務網站，就會產生比較嚴重的響應延遲。
其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。下面的例子就用鎖定表的方法來完成前面一個例子中事務的功能。
LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...
UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES
這里，我們用一個 SELECT 語句取出初始數據，通過一些計算，用 UPDATE 語句將新值更新到表中。包含有 WRITE 關鍵字的 LOCK TABLE 語句可以保證在 UNLOCK TABLES 命令被執行之前，不會有其它的訪問來對 inventory 進行插入、更新或者刪除的操作。
6、使用外鍵
鎖定表的方法可以維護數據的完整性，但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。例如，外鍵可以保證每一條銷售記錄都指向某一個存在的客戶。在這里，外鍵可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一條沒有合法CustomerID的記錄都不會被更新或插入到salesinfo中。
CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;
注意例子中的參數「ON DELETE CASCADE」。該參數保證當 customerinfo 表中的一條客戶記錄被刪除的時候，salesinfo 表中所有與該客戶相關的記錄也會被自動刪除。如果要在 MySQL 中使用外鍵，一定要記住在創建表的時候將表的類型定義為事務安全表 InnoDB類型。該類型不是 MySQL 表的默認類型。定義的方法是在 CREATE TABLE 語句中加上 TYPE=INNODB。如例中所示。
7、使用索引
索引是提高資料庫性能的常用方法，它可以令資料庫伺服器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(), MIN()和ORDERBY這些命令的時候，性能提高更為明顯。那該對哪些欄位建立索引呢？一般說來，索引應建立在那些將用於JOIN, WHERE判斷和ORDER BY排序的欄位上。盡量不要對資料庫中某個含有大量重復的值的欄位建立索引。對於一個ENUM類型的欄位來說，出現大量重復值是很有可能的情況，例如customerinfo中的「province」.. 欄位，在這樣的欄位上建立索引將不會有什麼幫助；相反，還有可能降低資料庫的性能。我們在創建表的時候可以同時創建合適的索引，也可以使用ALTER TABLE或CREATE INDEX在以後創建索引。此外，MySQL
從版本3.23.23開始支持全文索引和搜索。全文索引在MySQL 中是一個FULLTEXT類型索引，但僅能用於MyISAM 類型的表。對於一個大的資料庫，將數據裝載到一個沒有FULLTEXT索引的表中，然後再使用ALTER TABLE或CREATE INDEX創建索引，將是非常快的。但如果將數據裝載到一個已經有FULLTEXT索引的表中，執行過程將會非常慢。
8、優化的查詢語句
絕大多數情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當的話，索引將無法發揮它應有的作用。下面是應該注意的幾個方面。首先，最好是在相同類型的欄位間進行比較的操作。在MySQL 3.23版之前，這甚至是一個必須的條件。例如不能將一個建有索引的INT欄位和BIGINT欄位進行比較；但是作為特殊的情況，在CHAR類型的欄位和VARCHAR類型欄位的欄位大小相同的時候，可以將它們進行比較。其次，在建有索引的欄位上盡量不要使用函數進行操作。
例如，在一個DATE類型的欄位上使用YEAE()函數時，將會使索引不能發揮應有的作用。所以，下面的兩個查詢雖然返回的結果一樣，但後者要比前者快得多。
SELECT * FROM order WHERE YEAR(OrderDate)<2001;
SELECT * FROM order WHERE OrderDate<"2001-01-01";
同樣的情形也會發生在對數值型欄位進行計算的時候：
SELECT * FROM inventory WHERE Amount/7<24;
SELECT * FROM inventory WHERE Amount<24*7;
上面的兩個查詢也是返回相同的結果，但後面的查詢將比前面的一個快很多。第三，在搜索字元型欄位時，我們有時會使用 LIKE 關鍵字和通配符，這種做法雖然簡單，但卻也是以犧牲系統性能為代價的。例如下面的查詢將會比較表中的每一條記錄。
SELECT * FROM books
WHERE name like "MySQL%"
但是如果換用下面的查詢，返回的結果一樣，但速度就要快上很多：
SELECT * FROM books
WHERE name>="MySQL"and name<"MySQM"
最後，應該注意避免在查詢中讓MySQL進行自動類型轉換，因為轉換過程也會使索引變得不起作用。
『柒』 性能測試如何確定資料庫是否是瓶頸
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。