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進行自動類型轉換，因為轉換過程也會使索引變得不起作用。
❷ 資料庫都有哪些
一、資料庫種類有哪些
早期較為時興的資料庫種類有三種，分別是層次式資料庫、網路式資料庫和關系型資料庫。而在如今的互聯網中，最常見的資料庫種類主要有2種，即關系型資料庫和非關系型資料庫。
二、層次資料庫介紹
層次資料庫是最開始研製的資料庫系統軟體，它把數據根據層次構造（樹結構）的方法呈現。層次資料庫以前是非常熱門的資料庫，但伴隨著關系資料庫的逐漸流行，如今早已非常少應用了。
較為具備象徵性的層次資料庫是IMS（Information Management System）資料庫，由IBM企業研發。
三、關系型資料庫詳細介紹
網路資料庫和層次資料庫在數據獨立性和抽象性級別上有所欠缺，用戶開展存儲時，需要聲明數據的存儲結構和相對路徑。而關系資料庫就可以較切實解決這種問題。
和Excel工作簿一樣，關系型資料庫也選用由列和行構成的二維表來管理數據，簡單易懂。另外，它還利用SQL（Structured Query Language，結構化查詢語言）對數據開展實際操作。
四、非關系型資料庫詳細介紹
伴隨著互聯網技術Web2.0的興起，傳統關系型資料庫在應對大數據量，比如大規模和高並發的微博、微信或者SNS類型的web2.0動態網頁時，已經有些力不從心，曝露了許多難以克服的難題。因此出現了針對大規模數據量場景，以性能卓越和應用便捷為目的的的資料庫產品——NOSQL資料庫。
❸ 哪一類數據更適合使用雲資料庫mysql來存儲
視頻、游戲等行業的核心存儲通常使用雲資料庫MySQL。
雲資料庫MySQL提供主從數據存儲，保障線上數據安全，具有高可靠性；完善的數據自動備份機制，數據可保留時間長，具有高可用性。高性能、高可靠等性能，因此可輕松應對移動在線游戲服務部署。
雲資料庫MySQL的性能優勢：第一，強大的彈性擴展能；第二，超高的性能；第三，方便實惠：只需單擊滑鼠就可完成操作；第四，擁有智能運維支撐；第五，安全可靠。
❹ 如何查看mysql資料庫的性能
如何提高MySQL Limit查詢的性能?
在MySQL資料庫操作中，我們在做一些查詢的時候總希望能避免資料庫引擎做全表掃描，因為全表掃描時間長，而且其中大部分掃描對客戶端而言是沒有意義的。其實我們可以使用Limit關鍵字來避免全表掃描的情況，從而提高效率。
有個幾千萬條記錄的表 on MySQL 5.0.x，現在要讀出其中幾十萬萬條左右的記錄。常用方法，依次循環：
select * from mytable where index_col = xxx limit offset, limit;
經驗：如果沒有blob/text欄位，單行記錄比較小，可以把 limit 設大點，會加快速度。
問題：頭幾萬條讀取很快，但是速度呈線性下降，同時 mysql server cpu 99% ，速度不可接受。
調用 explain select * from mytable where index_col = xxx limit offset, limit;
顯示 type = ALL
在 MySQL optimization 的文檔寫到"All"的解釋
A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that allow row retrieval from the table based on constant values or column values from earlier tables.
看樣子對於 all, mysql 就使用比較笨的方法，那就改用 range 方式？ 因為 id 是遞增的，也很好修改 sql 。
select * from mytable where id > offset and id < offset + limit and index_col = xxx
explain 顯示 type = range，結果速度非常理想，返回結果快了幾十倍。
Limit語法：
SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset
LIMIT子句可以被用於強制 SELECT 語句返回指定的記錄數。LIMIT接受一個或兩個數字參數。參數必須是一個整數常量。
如果給定兩個參數，第一個參數指定第一個返回記錄行的偏移量，第二個參數指定返回記錄行的最大數目。初始記錄行的偏移量是 0(而不是 1)。
為了與 PostgreSQL 兼容，MySQL 也支持句法：LIMIT # OFFSET #。
mysql> SELECT * FROM table LIMIT 5,10; //檢索記錄行6-15
//為了檢索從某一個偏移量到記錄集的結束所有的記錄行，可以指定第二個參數為-1
mysql> SELECT * FROM table LIMIT 95,-1; //檢索記錄行96-last
//如果只給定一個參數，它表示返回最大的記錄行數目，換句話說，LIMIT n 等價於 LIMIT 0,n
mysql> SELECT * FROM table LIMIT 5; //檢索前5個記錄行
MySQL的limit給分頁帶來了極大的方便，但數據量一大的時候，limit的性能就急劇下降。同樣是取10條數據，下面兩句就不是一個數量級別的。
select * from table limit 10000,10
select * from table limit 0,10
文中不是直接使用limit，而是首先獲取到offset的id然後直接使用limit size來獲取數據。根據他的數據，明顯要好於直接使用limit。
這里我具體使用數據分兩種情況進行測試。
1、offset比較小的時候：
select * from table limit 10,10
//多次運行，時間保持在0.0004-0.0005之間
Select * From table Where vid ＞=(Select vid From table Order By vid limit 10,1) limit 10
//多次運行，時間保持在0.0005-0.0006之間，主要是0.0006
結論：偏移offset較小的時候，直接使用limit較優。這個顯然是子查詢的原因。
2、offset大的時候：
select * from table limit 10000,10
//多次運行，時間保持在0.0187左右
Select * From table Where vid ＞=(Select vid From table Order By vid limit 10000,1) limit 10
//多次運行，時間保持在0.0061左右，只有前者的1/3。可以預計offset越大，後者越優。
❺ mysql資料庫中，關於數據表性能的問題
MySQL 對於千萬級的大表的優化：
常用的優化sql----突出快字，使完成操作的時間最短
1、用索引提高效率：
2、選擇有效率的表名順序，及數據結構及欄位；
3、使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表；
4、刪除重復記；
5、過內部函數提高SQL效率；......
讀寫分離-----操作不在一個表裡完成
1、主資料庫A，進行事務性增、改、刪操作（INSERT、UPDATE、DELETE）；
2、從資料庫B，進行SELECT查詢操作；
3、A復制到B，使數據保持一致性；
垂直劃分 ------數據不存儲在一個伺服器里
按照功能劃分，把數據分別放到不同的資料庫和伺服器。如博客功能的放到伺服器A，儲存文件放到伺服器B；
水平劃分------相同數據結構的數據不放在一張表裡
把一個表的數據根據一定的規則劃分到不同的資料庫，兩個資料庫的表結構一樣。
數據歸檔處理-----時間優先原則存儲讀取
將資料庫中不經常使用的數據遷移至近線設備，將長期不使用的數據遷移至文件形式歸檔。這樣，隨著應用的需要，數據會在在線、近線和文件文檔之間移動，如當應用需要訪問很久以前的某些數據，它們的物理位置在近線設備，則會自動移動到在線設備。對用戶的應用而言，這些都是透明的，就像所有數據都存放在在線設備一樣，不會對資料庫應用產生任何影響。
❻ 哪些因素會對mysql資料庫伺服器性能造成影響
網路寬頻也會有所影響。
網路是資料庫基礎架構的主要部分。但是，通常性能基準測試是在本地計算機上完成的，客戶端和伺服器並置在一起。這樣做是為了簡化結構並排除一個以上的變數（網路部分），但是我們也忽略了網路對性能的影響。對於像 MySQL Group Replication 這樣的產品集群來說，網路更為重要。在這篇文章中，我將介紹網路設置。這些都是簡單而微不足道的，但卻是讓我們更了解復雜網路設置效果的基石。
安裝我將使用兩台裸機伺服器，通過專用的 10Gb 網路連接。我將通過使用 ethtool-s eth1 speed1000plex full autoneg off 命令更改網路介面速度來模擬 1Gb 網路。
我將運行一個簡單的基準：sysbench oltp_read_only --mysql-ssl=on --mysql-host=172.16.0.1 --tables=20 --table-size=10000000 --mysql-user=sbtest --mysql-password=sbtest --threads=$i --time=300 --report-interval=1 --rand-type=pareto
運行時線程數從 1 到 2048 不等。所有數據都適合內存 -innodb_buffer_pool_size 足夠大。因此工作負載在內存中佔用大量 CPU：沒有 IO 開銷。操作系統：Ubuntu 16.04
N1 基準-網路帶寬在第一個實驗中，我將比較 1Gb 網路和 10Gb 網路。
但是 10Gb 網路不是這種情況。壓縮/解壓縮所需的 CPU 資源是一個限制因素，通過壓縮，吞吐量實際上只達到我們沒有壓縮的一半。現在讓我們談談協議加密，以及如何使用 SSL 影響我們的結果。
N3基準-網路加密
對於 1Gb 網路，SSL 加密顯示了一些損失 - 單線程約為 10％ - 但是否則我們再次達到帶寬限制。我們還看到了大量線程的可擴展性，這在 10Gb 網路案例中更為明顯。使用 10Gb 時，SSL 協議在 32 個線程後不會擴展。實際上，它似乎是 MySQL 目前使用的 OpenSSL 1.0 中的可伸縮性問題。在我們的實驗中，我們看到 OpenSSL 1.1.1 提供了更好的可伸縮性，但是您需要從鏈接到OpenSSL 1.1.1 的源代碼中獲得特殊的 MySQL 構建才能實現這一點。我沒有在這里展示它們，因為我們沒有生產二進制文件。
結論
1. 網路性能和利用率將影響一般應用程序吞吐量。
2. 檢查您是否達到了網路帶寬限制。
3. 如果受到網路帶寬的限制，協議壓縮可以改善結果，但如果不是，則可能會使事情變得更糟。
4. SSL 加密在線程數量較少的情況下會有一些損失（約10％），但對於高並發工作負載，它不會擴展。
❼ 如何測試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》）