061 如何刪除表？
答案：運行命令 drop table table_name;
062 創建索引
對於查詢占主要的應用來說，索引顯得尤為重要。很多時候性能問題很簡單的就是因為我們忘了添加索引而造成的，或者說沒有添加更為有效的索引導致。如果不加索引的話，那么查找任何哪怕只是一條特定的數據都會進行一次全表掃描，如果一張表的數據量很大而符合條件的結果又很少，那么不加索引會引起致命的性能下降。但是也不是什么情 況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什么優勢，還會影響到更新速度，這被稱為過度索引。
063 復合索引
比如有一條語句是這樣的：select * from users where area=’beijing’ and age=22;
如果我們是在area和age上分別創建單個索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果在area、age兩列上創建復合索引的話將帶來更高的效率。如果我們創建了(area, age, salary)的復合索引，那么其實相當於創建了(area,age,salary)、 (area,age)、(area)三個索引，這被稱為最佳左前綴特性。因此我們在創建復合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
064 索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那么這一列對於此復合索引就是無效的。所以我們在數據庫設計時不要讓字段的默認值為NULL。
065 使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的列，如果在前10個或20個字符內，多數值是惟一的，那么就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁盤空間和I/O操作。
066 排序的索引問題
mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那么order by中的列是不會使用索引的。因此數據庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
067 like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like “%aaa%” 不會使用索引而like “aaa%”可以使用索引。
數據庫設計數據類型選擇需要注意哪些地方">068 MYSQL數據庫設計數據類型選擇需要注意哪些地方?
VARCHAR和CHAR類型，varchar是變長的，需要額外的1-2個字節存儲，能節約空間，可能會對性能有幫助。但由於是變長，可能發生碎片，如更新數據；
使用ENUM（MySQL的枚舉類）代替字符串類型，數據實際存儲為整型。
字符串類型
要盡可能地避免使用字符串來做標識符，因為它們占用了很多空間並且通常比整數類型要慢。特別注意不要在MYISAM表上使用字符串標識符。MYISAM默認情況下為字符串使用了壓縮索引（Packed Index），這使查找更為緩慢。據測試，使用了壓縮索引的MYISAM表性能要慢6倍。
還要特別注意完全‘隨機’的字符串，例如由MD5（）、SHA1（）、UUID（）產生的。它們產生的每一個新值都會被任意地保存在很大的空間范圍內，這會減慢INSERT及一些SELECT查詢。1）它們會減慢INSERT查詢，因為插入的值會被隨機地放入索引中。這會導致分頁、隨機磁盤訪問及聚集存儲引擎上的聚集索引碎片。2)它們會減慢SELECT查詢，因為邏輯上相鄰的行會分布在磁盤和內存中的各個地方。3）隨機值導致緩存對所有類型的查詢性能都很差，因為它們會使緩存賴以工作的訪問局部性失效。如果整個數據集都變得同樣“熱”的時候，那么把特定部分的數據緩存到內存中就沒有任何的優勢了。並且如果工作集不能被裝入內存中，緩存就會進行很多刷寫的工作，並且會導致很多緩存未命中。
如果保存UUID值，就應該移除其中的短橫線，更好的辦法是使用UHEX（）把UUID值轉化為16字節的數字，並把它保存在BINARY（16）列中。
069 不要在列上進行運算
select * from users where YEAR(adddate)<2007;
將在每個行上進行運算，這將導致索引失效而進行全表掃描，因此我們可以改成
select * from users where adddate<‘2007-01-01’;
不使用NOT IN和操作
NOT IN和操作都不會使用索引將進行全表掃描。NOT IN可以NOT EXISTS代替，id != 3則可使用id>3 or id<3來代替。
070 IS NULL 與 IS NOT NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。
任何在where子句中使用is null或is not null的語句優化器是不允許使用索引的。
071 聯接列
對於有聯接的列，即使最后的聯接值為一個靜態值，優化器是不會使用索引的。
072 MySQL幾種備份方式（重點）
1、邏輯備份：使用mysql自帶的mysqldump工具進行備份。備份成sql文件形式。
優點：最大好處是能夠與正在運行的mysql自動協同工作，在運行期間可以確保備份是當時的點，它會自動將對應操作的表鎖定，不允許其他用戶修改(只能訪問)。可能會阻止修改操作。sql文件通用方便移植。
缺點：備份的速度比較慢。如果是數據量很多的時候。就很耗時間。如果數據庫服務器處在提供給用戶服務狀態，在這段長時間操作過程中，意味着要鎖定表(一般是讀鎖定，只能讀不能寫入數據)。那么服務就會影響的。
2、物理備份：直接拷貝mysql的數據目錄。
直接拷貝只適用於myisam類型的表。這種類型的表是與機器獨立的。但實際情況是，你設計數據庫的時候不可能全部使用myisam類型表。你也不可能因為myisam類型表與機器獨立，方便移植，於是就選擇這種表，這並不是選擇它的理由。
缺點：你不能去操作正在運行的mysql服務器(在拷貝的過程中有用戶通過應用程序訪問更新數據，這樣就無法備份當時的數據)可能無法移植到其他機器上去。
3、雙機熱備份。
mysql數據庫沒有增量備份的機制。當數據量太大的時候備份是一個很大的問題。還好mysql數據庫提供了一種主從備份的機制(也就是雙機熱備)
優點：適合數據量大的時候。現在明白了。大的互聯網公司對於mysql數據備份，都是采用熱機備份。搭建多台數據庫服務器，進行主從復制。
073 想知道一個查詢用到了哪個index,如何查看?
explain顯示了mysql如何使用索引來處理select語句以及連接表。可以幫助選擇更好的索引和寫出更優化的查詢語句。使用方法，在select語句前加上explain就可以了。所以使用explain可以查看。
074 數據庫不能停機，請問如何備份? 如何進行全備份和增量備份?
可以使用邏輯備份和雙機熱備份。
完全備份：完整備份一般一段時間進行一次，且在網站訪問量最小的時候，這樣常借助批處理文件定時備份。主要是寫一個批處理文件在里面寫上處理程序的絕對路徑然后把要處理的東西寫在后面，即完全備份數據庫。
增量備份：對ddl和dml語句進行二進制備份。且5.0無法增量備份，5.1后可以。如果要實現增量備份需要在my.ini文件中配置備份路徑即可，重啟mysql服務器，增量備份就啟動了。
075 MySQL添加索引
普通索引 添加INDEX
ALTER TABLE ‘table_name’ ADD INDEX index_name (‘column’);
主鍵索引 添加PRIMARY KEY
ALTER TABLE ‘table_name’ ADD PRIMARY KEY (‘column’);
唯一索引 添加UNIQUE
ALTER TABLE ‘table_name’ ADD UNIQUE (‘column’);
全文索引 添加FULLTEXT
ALTER TABLE ‘table_name’ ADD FULLTEXT (‘column’);
多列索引
ALTER TABLE ‘table_name’ ADD INDEX index_name (‘column1’, ‘column2’, ‘column3’)
076 什么情況下使用索引？
表的主關鍵字
自動建立唯一索引
如zl_yhjbqk（用戶基本情況）中的hbs_bh（戶標識編號）
表的字段唯一約束
ORACLE利用索引來保證數據的完整性
如lc_hj（流程環節）中的lc_bh+hj_sx（流程編號+環節順序）
直接條件查詢的字段
在SQL中用於條件約束的字段
如zl_yhjbqk（用戶基本情況）中的qc_bh（區冊編號）
select * from zl_yhjbqk where qc_bh=’7001’
查詢中與其它表關聯的字段
字段常常建立了外鍵關系
如zl_ydcf（用電成份）中的jldb_bh（計量點表編號）
select * from zl_ydcf a,zl_yhdb b where a.jldb_bh=b.jldb_bh and b.jldb_bh=’540100214511’
查詢中排序的字段
排序的字段如果通過索引去訪問那將大大提高排序速度
select * from zl_yhjbqk order by qc_bh（建立qc_bh索引）
select * from zl_yhjbqk where qc_bh=’7001’ order by cb_sx（建立qc_bh+cb_sx索引，注：只是一個索引，其中包括qc_bh和cb_sx字段）
查詢中統計或分組統計的字段
select max(hbs_bh) from zl_yhjbqk
select qc_bh,count(*) from zl_yhjbqk group by qc_bh
077 什么情況下應不建或少建索引
表記錄太少
如果一個表只有5條記錄，采用索引去訪問記錄的話，那首先需訪問索引表，再通過索引表訪問數據表，一般索引表與數據表不在同一個數據塊，這種情況下ORACLE至少要往返讀取數據塊兩次。而不用索引的情況下ORACLE會將所有的數據一次讀出，處理速度顯然會比用索引快。
如表zl_sybm（使用部門）一般只有幾條記錄，除了主關鍵字外對任何一個字段建索引都不會產生性能優化，實際上如果對這個表進行了統計分析后ORACLE也不會用你建的索引，而是自動執行全表訪問。如：select * from zl_sybm where sydw_bh=’5401’（對sydw_bh建立索引不會產生性能優化）
經常插入、刪除、修改的表
對一些經常處理的業務表應在查詢允許的情況下盡量減少索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等業務表。
數據重復且分布平均的表字段
假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每個值的分布概率大約為50%，那么對這種表A字段建索引一般不會提高數據庫的查詢速度。
經常和主字段一塊查詢但主字段索引值比較多的表字段
如gc_dfss（電費實收）表經常按收費序號、戶標識編號、抄表日期、電費發生年月、操作 標志來具體查詢某一筆收款的情況，如果將所有的字段都建在一個索引里那將會增加數據的修改、插入、刪除時間，從實際上分析一筆收款如果按收費序號索引就已 經將記錄減少到只有幾條，如果再按后面的幾個字段索引查詢將對性能不產生太大的影 響。
078 千萬級MySQL數據庫建立索引的事項及提高性能的手段
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num is null可以在num上設置默認值0，確保表中num列沒有null值，然后這樣查詢：select id from t where num=0
3.應盡量避免在 where 子句中使用!=或<>操作符，否則引擎將放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num=10 or num=20可以這樣查詢：select id from t where num=10 union all select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：select id from t where num in(1,2,3) 對於連續的數值，能用 between 就不要用 in 了：select id from t where num between 1 and 3
6.避免使用通配符。下面的查詢也將導致全表掃描：select id from t where name like ‘李%’若要提高效率，可以考慮全文檢索。
7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計划的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計划，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：select id from t where num=@num可以改為強制查詢使用索引：select id from t with(index(索引名)) where num=@num
8.應盡量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：select id from t where num/2=100應改為:select id from t where num=100*2
9.應盡量避免在where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：select id from t where substring(name,1,3)=’abc’ ，name以abc開頭的id應改為:select id from t where name like ‘abc%’
10.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11.在使用索引字段作為條件時，如果該索引是復合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致。
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：select col1,col2 into #t from t where 1=0 這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：create table #t(…)
13.很多時候用 exists 代替 in 是一個好的選擇：select num from a where num in(select num from b)用下面的語句替換：select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了insert 及 update 的 效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲 順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那么需要考慮是否應將該索引建為 clustered 索引。
17.盡量使用數字型字段，若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。
20.盡量使用表變量來代替臨時表。如果表變量包含大量數據，請注意索引非常有限（只有主鍵索引）。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
23.在新建臨時表時，如果一次性插入數據量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然后insert。
24.如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統表的較長時間鎖定。
25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那么就應該考慮改寫。
26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括“合計”的例程通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF。無需在執行存儲過程和觸發器的每個語句后向客戶端發送DONE_IN_PROC 消息。
29.盡量避免大事務操作，提高系統並發能力。
30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
079 MySql在建立索引優化時需要注意的問題
1，創建索引
對於查詢占主要的應用來說，索引顯得尤為重要。很多時候性能問題很簡單的就是因為我們忘了添加索引而造成的，或者說沒有添加更為有效的索引導致。如果不加索引的話，那么查找任何哪怕只是一條特定的數據都會進行一次全表掃描，如果一張表的數據量很大而符合條件的結果又很少，那么不加索引會引起致命的性能下降。但是也不是什么情況都非得建索引不可，比如性別可能就只有兩個值，建索引不僅沒什么優勢，還會影響到更新速度，這被稱為過度索引。
2，復合索引
比如有一條語句是這樣的：select * from users where area=’beijing’ and age=22;
如果我們是在area和age上分別創建單個索引的話，由於mysql查詢每次只能使用一個索引，所以雖然這樣已經相對不做索引時全表掃描提高了很多效率，但是如果在area、age兩列上創建復合索引的話將帶來更高的效率。如果我們創建了(area, age,salary)的復合索引，那么其實相當於創建了(area,age,salary)、(area,age)、(area)三個索引，這被稱為最佳左前綴特性。因此我們在創建復合索引時應該將最常用作限制條件的列放在最左邊，依次遞減。
3，索引不會包含有NULL值的列
只要列中包含有NULL值都將不會被包含在索引中，復合索引中只要有一列含有NULL值，那么這一列對於此復合索引就是無效的。所以我們在數據庫設計時不要讓字段的默認值為NULL。
4，使用短索引
對串列進行索引，如果可能應該指定一個前綴長度。例如，如果有一個CHAR(255)的 列，如果在前10 個或20 個字符內，多數值是惟一的，那么就不要對整個列進行索引。短索引不僅可以提高查詢速度而且可以節省磁盤空間和I/O操作。
5，排序的索引問題
mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那么order by中的列是不會使用索引的。因此數據庫默認排序可以符合要求的情況下不要使用排序操作；盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
6，like語句操作
一般情況下不鼓勵使用like操作，如果非使用不可，如何使用也是一個問題。like “%aaa%” 不會使用索引而like “aaa%”可以使用索引。
7，不要在列上進行運算
select * from users where YEAR(adddate)
8，不使用NOT IN和操作
NOT IN和操作都不會使用索引將進行全表掃描。NOT IN可以NOT EXISTS代替，id != 3則可使用id>3 or id < 3
080 數據庫性能下降，想找到哪些sql耗時較長，應該如何操作? my.cnf里如何配置?
1、show processlist;
2、select * from information_schema.processlist ;
3、可以在[mysqld]中添加如下：
log =/var/log/mysql.log
如果需要監控慢查詢可以添加如下內容：
log-slow-queries = /var/log/slowquery.log
long_query_time = 1
081 聚集索引
術語“聚集”指實際的數據行和相關的鍵值都保存在一起。每個表只能有一個聚集索引。但是，覆蓋索引可以模擬多個聚集索引。存儲引擎負責實現索引，因此不是所有的存儲索引都支持聚集索引。當前，SolidDB和InnoDB是唯一支持聚集索引的存儲引擎。
優點：
可以把相關數據保存在一起。這樣從磁盤上提取幾個頁面的數據就能把某個用戶的數據全部抓取出來。如果沒有使用聚集，讀取每個數據都會訪問磁盤。
數據訪問快。聚集索引把索引和數據都保存到了同一棵B-TREE中，因此從聚集索引中取得數據通常比在非聚集索引進行查找要快。
缺點：
聚集能最大限度地提升I/O密集負載的性能。如果數據能裝入內存，那么其順序也就無所謂了。這樣聚集就沒有什么用處。
插入速度嚴重依賴於插入順序。更新聚集索引列是昂貴的，因為強制InnoDB把每個更新的行移到新的位置。
建立在聚集索引上的表在插入新行，或者在行的主鍵被更新，該行必須被移動的時候會進行分頁。
聚集表可會比全表掃描慢，尤其在表存儲得比較稀疏或因為分頁而沒有順序存儲的時候。
第二（非聚集）索引可能會比預想的大，因為它們的葉子節點包含了被引用行的主鍵列。第二索引訪問需要兩次索引查找，而不是一次。 InnoDB的第二索引葉子節點包含了主鍵值作為指向行的“指針”，而不是“行指針”。 這種策略減少了在移動行或數據分頁的時候索引的維護工作。使用行的主鍵值作為指針使得索引變得更大，但是這意味着InnoDB可以移動行，而無須更新指針。
082 索引類型
索引類型: B-TREE索引，哈希索引
B-TREE索引(默認的索引類型)加速了數據訪問，因為存儲引擎不會掃描整個表得到需要的數據。相反，它從根節點開始。根節點保存了指向子節點的指針，並且存儲引擎會根據指針尋找數據。它通過查找節點頁中的值找到正確的指針，節點頁包含子節點的指針，並且存儲引擎會根據指針尋找數據。它通過查找節點頁中的值找到正確的指針，節點頁包含子節點中值的上界和下界。最后，存儲引擎可能無法找到需要的數據，也可能成功地找到包含數據的葉子頁面。
例：B-TREE索引 對於以下類型查詢有用。匹配全名、匹配最左前綴、匹配列前綴、匹配范圍值、精確匹配一部分並且匹配某個范圍中的另一部分；
B-TREE索引的局限：如果查找沒有從索引列的最左邊開始，它就沒什么用處。不能跳過索引中的列，存儲引擎不能優先訪問任何在第一個范圍條件右邊的列。例：如果查詢是where last_name=’Smith’ AND first_name LIKE ‘J%’ AND dob=’1976-12-23’;訪問就只能使用索引的頭兩列，因為LIKE是范圍條件。
哈希索引建立在哈希表的基礎上，它只對使用了索引中的每一列的精確查找有用。對於每一行，存儲引擎計算出了被索引列的哈希碼，它是一個較小的值，並且有可能和其他行的哈希碼不同。它把哈希碼保存在索引中，並且保存了一個指向哈希表中每一行的指針。
因為索引只包含了哈希碼和行指針，而不是值自身，MYSQL不能使用索引中的值來避免讀取行。
MYSQL不能使用哈希索引進行排序，因為它們不會按序保存行。
哈希索引不支持部分鍵匹配，因為它們是由被索引的全部值計算出來的。也就是說，如果在（A，B）兩列上有索引，並且WHERE子句中只使用了A，那么索引就不會起作用。
哈希索引只支持使用了= IN（）和<=>的相等比較。它們不能加快范圍查詢。例如WHERE price > 100;
訪問哈希索引中的數據非常快，除非碰撞率很高。當發生碰撞的時候，存儲引擎必須訪問鏈表中的每一個行指針，然后逐行進行數據比較，以確定正確的數據。如果有很多碰撞，一些索引維護操作就有可能會變慢。
083 FULLTEXT全文索引
即為全文索引，目前只有MyISAM引擎支持。其可以在CREATE TABLE ，ALTER TABLE ，CREATE INDEX 使用，不過目前只有 CHAR、VARCHAR ，TEXT 列上可以創建全文索引。值得一提的是，在數據量較大時候，現將數據放入一個沒有全局索引的表中，然后再用CREATE INDEX創建FULLTEXT索引，要比先為一張表建立FULLTEXT然后再將數據寫入的速度快很多。FULLTEXT索引也是按照分詞原理建立索引的。西文中，大部分為字母文字，分詞可以很方便的按照空格進行分割。中文不能按照這種方式進行分詞。Mysql的中文分詞插件Mysqlcft，有了它，就可以對中文進行分詞。
084 介紹一下如何優化MySql
一、在編譯時優化MySQL
如果你從源代碼分發安裝MySQL，要注意，編譯過程對以后的目標程序性能有重要的影響，不同的編譯方式可能得到類似的目標文件，但性能可能相差很大，因此，在編譯安裝MySQL適應仔細根據你的應用類型選擇最可能好的編譯選項。這種定制的MySQL可以為你的應用提供最佳性能。
技巧：選用較好的編譯器和較好的編譯器選項，這樣應用可提高性能10-30%。（MySQL文檔如是說）
1.1、使用pgcc（Pentium GCC)編譯器->（使用合適的編譯器）
該編譯器（http://www.goof.com/pcg/）針對運行在奔騰處理器系統上的程序進行優化，用pgcc編譯MySQL源代碼，總體性能可提高10%。當然如果你的服務器不是用奔騰處理器，就不必用它了，因為它是專為奔騰系統設計的。
1.2、僅使用你想使用的字符集編譯MySQL
MySQL目前提供多達24種不同的字符集，為全球用戶以他們自己的語言插入或查看表中的數據。卻省情況下，MySQL安裝所有者這些字符集，熱然而，最好的選擇是指選擇一種你需要的。如，禁止除Latin1字符集以外的所有其它字符集：
1.3、將mysqld編譯成靜態執行文件
將mysqld編譯成靜態執行文件而無需共享庫也能獲得更好的性能。通過在配置時指定下列選項，可靜態編譯mysqld。
1.4、配置樣本
二、調整服務器
三、表類型（MySQL中表的類型）
很多MySQL用戶可能很驚訝，MySQL確實為用戶提供5種不同的表類型，稱為DBD、HEAP、ISAM、MERGE和MyIASM。DBD歸為事務安全類，而其他為非事務安全類。
3.1、事務安全
DBD
Berkeley DB(DBD)表是支持事務處理的表，它提供MySQL用戶期待已久的功能-事務控制。事務控制在任何數據庫系統中都是一個極有價值的功能，因為它們確保一組命令能成功地執行。
3.2、非事務安全
HEAP
HEAP表是MySQL中存取數據最快的表。這是因為他們使用存儲在動態內存中的一個哈希索引。另一個要點是如果MySQL或服務器崩潰，數據將丟失。
ISAM
ISAM表是早期MySQL版本的缺省表類型，直到MyIASM開發出來。建議不要再使用它。
MERGE
MERGE是一個有趣的新類型，在3.23.25之后出現。一個MERGE表實際上是一個相同MyISAM表的集合，合並成一個表，主要是為了效率原因。這樣可以提高速度、搜索效率、修復效率並節省磁盤空間。
MyIASM
這是MySQL的缺省表類型(5.5.5之前)。它基於IASM代碼，但有很多有用的擴展。MyIASM比較好的原因：
MyIASM表小於IASM表，所以使用較少資源。
MyIASM表在不同的平台上二進制層可移植。
更大的鍵碼尺寸，更大的鍵碼上限。
3.3、指定表類型
四、優化工具
MySQL服務器本身提供了幾條內置命令用於幫助優化。
4.1、SHOW
SHOW還能做更多的事情。它可以顯示關於日志文件、特定數據庫、表、索引、進程和權限表中有價值的信息。
4.2、EXPLAIN
當你面對SELECT語句時，EXPLAIN解釋SELECT命令如何被處理。這不僅對決定是否應該增加一個索引，而且對決定一個復雜的Join如何被MySQL處理都是有幫助的。
4.3、OPTIMIZE
OPTIMIZE語句允許你恢復空間和合並數據文件碎片，對包含變長行的表進行了大量更新和刪除后，這樣做特別重要。OPTIMIZE目前只工作於MyIASM和BDB表。
085 MySQL你都修改了那些配置文件來進行優化(問配置文件中具體修改的內容)?
innodb_buffer_pool_size:這是你安裝完InnoDB后第一個應該設置的選項。緩沖池是數據和索引緩存的地方：這個值越大越好，這能保證你在大多數的讀取操作時使用的是內存而不是硬盤。典型的值是5-6GB(8GB內存)，20-25GB(32GB內存)，100-120GB(128GB內存)。
innodb_log_file_size：這是redo日志的大小。redo日志被用於確保寫操作快速而可靠並且在崩潰時恢復。一直到MySQL 5.1，它都難於調整，因為一方面你想讓它更大來提高性能，另一方面你想讓它更小來使得崩潰后更快恢復。幸運的是從MySQL 5.5之后，崩潰恢復的性能的到了很大提升，這樣你就可以同時擁有較高的寫入性能和崩潰恢復性能了。一直到MySQL 5.5，redo日志的總尺寸被限定在4GB(默認可以有2個log文件)。這在MySQL 5.6里被提高。
一開始就把innodb_log_file_size設置成512M(這樣有1GB的redo日志)會使你有充裕的寫操作空間。如果你知道你的應用程序需要頻繁的寫入數據並且你使用的時MySQL 5.6，你可以一開始就把它這是成4G。max_connections:如果你經常看到‘Too many connections’錯誤，是因為max_connections的值太低了。這非常常見因為應用程序沒有正確的關閉數據庫連接，你需要比默認的151連接數更大的值。max_connection值被設高了(例如1000或更高)之后一個主要缺陷是當服務器運行1000個或更高的活動事務時會變的沒有響應。在應用程序里使用連接池或者在MySQL里使用進程池有助於解決這一問題。
InnoDB配置
從MySQL 5.5版本開始，InnoDB就是默認的存儲引擎並且它比任何其他存儲引擎的使用都要多得多。那也是為什么它需要小心配置的原因。
innodb_file_per_table：這項設置告知InnoDB是否需要將所有表的數據和索引存放在共享表空間里 （innodb_file_per_table = OFF）或者為每張表的數據單獨放在一個.ibd文件（innodb_file_per_table = ON）。每張表一個文件允許你在drop、truncate或者rebuild表時回收磁盤空間。這對於一些高級特性也是有必要的，比如數據壓縮。但是它不會帶來任何性能收益。你不想讓每張表一個文件的主要場景是：有非常多的表（比如10k+）。
MySQL 5.6中，這個屬性默認值是ON，因此大部分情況下你什么都不需要做。對於之前的版本你必需在加載數據之前將這個屬性設置為ON，因為它只對新創建的表有影響。
innodb_flush_log_at_trx_commit：默認值為1，表示InnoDB完全支持ACID特性。當你的主要關注點是數據安全的時候這個值是最合適的，比如在一個主節點上。但是對於磁盤（讀寫）速度較慢的系統，它會帶來很巨大的開銷，因為每次將改變flush到redo日志都需要額外的fsyncs。將它的值設置為2會導致不太可靠（reliable）因為提交的事務僅僅每秒才flush一次到redo日志，但對於一些場景是可以接受的，比如對於主節點的備份節點這個值是可以接受的。如果值為0速度就更快了，但在系統崩潰時可能丟失一些數據：只適用於備份節點。
innodb_flush_method: 這項配置決定了數據和日志寫入硬盤的方式。一般來說，如果你有硬件RAID控制器，並且其獨立緩存采用write-back機制，並有着電池斷電保護，那么應該設置配置為O_DIRECT；否則，大多數情況下應將其設為fdatasync（默認值）。sysbench是一個可以幫助你決定這個選項的好工具。
innodb_log_buffer_size: 這項配置決定了為尚未執行的事務分配的緩存。其默認值（1MB）一般來說已經夠用了，但是如果你的事務中包含有二進制大對象或者大文本字段的話，這點緩存很快就會被填滿並觸發額外的I/O操作。看看Innodb_log_waits狀態變量，如果它不是0，增加innodb_log_buffer_size。
其他設置
query_cache_size: query cache（查詢緩存）是一個眾所周知的瓶頸，甚至在並發並不多的時候也是如此。 最佳選項是將其從一開始就停用，設置query_cache_size = 0（現在MySQL 5.6的默認值）並利用其他方法加速查詢：優化索引、增加拷貝分散負載或者啟用額外的緩存（比如memcache或redis）。如果你已經為你的應用啟用了query cache並且還沒有發現任何問題，query cache可能對你有用。這是如果你想停用它，那就得小心了。
log_bin：如果你想讓數據庫服務器充當主節點的備份節點，那么開啟二進制日志是必須的。如果這么做了之后，還別忘了設置server_id為一個唯一的值。就算只有一個服務器，如果你想做基於時間點的數據恢復，這（開啟二進制日志）也是很有用的：從你最近的備份中恢復（全量備份），並應用二進制日志中的修改（增量備份）。二進制日志一旦創建就將永久保存。所以如果你不想讓磁盤空間耗盡，你可以用 PURGE BINARY LOGS 來清除舊文件，或者設置 expire_logs_days 來指定過多少天日志將被自動清除。
記錄二進制日志不是沒有開銷的，所以如果你在一個非主節點的復制節點上不需要它的話，那么建議關閉這個選項。
skip_name_resolve：當客戶端連接數據庫服務器時，服務器會進行主機名解析，並且當DNS很慢時，建立連接也會很慢。因此建議在啟動服務器時關閉skip_name_resolve選項而不進行DNS查找。唯一的局限是之后GRANT語句中只能使用IP地址了，因此在添加這項設置到一個已有系統中必須格外小心。
086 MySQL調優?（重點）
I 硬件配置優化
? CPU選擇：多核的CPU，主頻高的CPU
? 內存：更大的內存
? 磁盤選擇：更快的轉速、RAID、陣列卡，
? 網絡環境選擇：盡量部署在局域網、SCI、光纜、千兆網、雙網線提供冗余、0.0.0.0多端口綁定監聽
II操作系統級優化
? 使用64位的操作系統，更好的使用大內存。
? 設置noatime,nodiratime
? 優化內核參數
? 加大文件描述符限制
? 文件系統選擇 xfs
III Mysql設計優化
III.1 存儲引擎的選擇
? Myisam：數據庫並發不大，讀多寫少,而且都能很好的用到索引，sql語句比較簡單的應用，TB數據倉庫
? Innodb：並發訪問大，寫操作比較多，有外鍵、事務等需求的應用，系統內存較大。
III.2 命名規則
? 多數開發語言命名規則：比如MyAdress
? 多數開源思想命名規則：my_address
? 避免隨便命名
III.3 字段類型選擇
字段類型的選擇的一般原則：
? 根據需求選擇合適的字段類型，在滿足需求的情況下字段類型盡可能小。
? 只分配滿足需求的最小字符數，不要太慷慨。 原因：更小的字段類型更小的字符數占用更少的內存，占用更少的磁盤空間，占用更少的磁盤IO，以及占用更少的帶寬。
對於varchar和char的選擇要根據引擎和具體情況的不同來選擇，主要依據如下原則:
1.如果列數據項的大小一致或者相差不大，則使用char。
2.如果列數據項的大小差異相當大，則使用varchar。
3.對於MyISAM表，盡量使用Char，對於那些經常需要修改而容易形成碎片的myisam和isam數據表就更是如此，它的缺點就是占用磁盤空間。
4.對於InnoDB表，因為它的數據行內部存儲格式對固定長度的數據行和可變長度的數據行不加區分（所有數據行共用一個表頭部分，這個標頭部分存放着指向各有關數據列的指針），所以使用char類型不見得會比使用varchar類型好。事實上，因為char類型通常要比varchar類型占用更多的空間，所以從減少空間占用量和減少磁盤i/o的角度，使用varchar類型反而更有利。
5.表中只要存在一個varchar類型的字段，那么所有的char字段都會自動變成varchar類型，因此建議定長和變長的數據分開。
III.4 編碼選擇
單字節 latin1
多字節 utf8(漢字占3個字節，英文字母占用一個字節)如果含有中文字符的話最好都統一采用utf8類型，避免亂碼的情況發生。
III.5 主鍵選擇原則
注：這里說的主鍵設計主要是針對INNODB引擎
1.能唯一的表示行。
2.顯式的定義一個數值類型自增字段的主鍵，這個字段可以僅用於做主鍵，不做其他用途。
3.MySQL主鍵應該是單列的，以便提高連接和篩選操作的效率。
4.主鍵字段類型盡可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT。
5.盡量保證不對主鍵字段進行更新修改，防止主鍵字段發生變化，引發數據存儲碎片，降低IO性能。
6.MySQL主鍵不應包含動態變化的數據，如時間戳、創建時間列、修改時間列等。
7.MySQL主鍵應當有計算機自動生成。
8.主鍵字段放在數據表的第一順序。
推薦采用數值類型做主鍵並采用auto_increment屬性讓其自動增長。
III.6 其他需要注意的地方
? NULL OR NOT NULL
盡可能設置每個字段為NOT NULL，除非有特殊的需求，原因如下：
1.使用含有NULL列做索引的話會占用更多的磁盤空間，因為索引NULL列需要而外的空間來保存。
2.進行比較的時候，程序會更復雜。
3.含有NULL的列比較特殊，SQL難優化，如果是一個組合索引，那么這個NULL 類型的字段會極大影響整個索引的效率。
? 索引
索引的優點：極大地加速了查詢，減少掃描和鎖定的數據行數。
索引的缺點：占用磁盤空間，減慢了數據更新速度，增加了磁盤IO。
添加索引有如下原則：
1 選擇唯一性索引。
2.為經常需要排序、分組和聯合操作的字段建立索引。
3.為常作為查詢條件的字段建立索引。
4.限制索引的數據，索引不是越多越好。
5.盡量使用數據量少的索引，對於大字段可以考慮前綴索引。
6.刪除不再使用或者很少使用的索引。
7.結合核心SQL優先考慮覆蓋索引。
8.忌用字符串做主鍵。
? 反范式設計
適當的使用冗余的反范式設計，以空間換時間有的時候會很高效。
IV Mysql軟件優化
? 開啟mysql復制，實現讀寫分離、負載均衡，將讀的負載分攤到多個從服務器上，提高服務器的處理能力。
? 使用推薦的GA版本，提升性能
? 利用分區新功能進行大數據的數據拆分
V Mysql配置優化
注意：全局參數一經設置，隨服務器啟動預占用資源。
? key_buffer_size參數
mysql索引緩沖，如果是采用myisam的話要重點設置這個參數，根據（key_reads/key_read_requests）判斷
? innodb_buffer_pool_size參數
INNODB 數據、索引、日志緩沖最重要的引擎參數，根據（hit riatos和FILE I/O）判斷
? wait_time_out參數
線程連接的超時時間，盡量不要設置很大，推薦10s
? max_connections參數
服務器允許的最大連接數，盡量不要設置太大，因為設置太大的話容易導致內存溢出
? thread_concurrency參數
線程並發利用數量，(cpu+disk)*2,根據(os中顯示的請求隊列和tickets)判斷
? sort_buffer_size參數
獲得更快的–ORDER BY,GROUP BY,SELECT DISTINCT,UNION DISTINCT
? read_rnd_buffer_size參數
當根據鍵進行分類操作時獲得更快的–ORDER BY
? join_buffer_size參數
join連接使用全表掃描連接的緩沖大小，根據select_full_join判斷
? read_buffer_size參數
全表掃描時為查詢預留的緩沖大小，根據select_scan判斷
? tmp_table_size參數
臨時內存表的設置，如果超過設置就會轉化成磁盤表，根據參數(created_tmp_disk_tables)判斷
? innodb_log_file_size參數(默認5M)
記錄INNODB引擎的redo log文件，設置較大的值意味着較長的恢復時間。
? innodb_flush_method參數(默認fdatasync)
Linux系統可以使用O_DIRECT處理數據文件，避免OS級別的cache，O_DIRECT模式提高數據文件和日志文件的IO提交性能
? innodb_flush_log_at_trx_commit(默認1)
1.0表示每秒進行一次log寫入cache，並flush log到磁盤。
2.1表示在每次事務提交后執行log寫入cache，並flush log到磁盤。
3.2表示在每次事務提交后，執行log數據寫入到cache，每秒執行一次flush log到磁盤。
VI Mysql語句級優化
1.性能查的讀語句，在innodb中統計行數,建議另外弄一張統計表，采用myisam，定期做統計.一般的對統計的數據不會要求太精准的情況下適用。
2.盡量不要在數據庫中做運算。
3.避免負向查詢和%前綴模糊查詢。
4.不在索引列做運算或者使用函數。
5.不要在生產環境程序中使用select * from 的形式查詢數據。只查詢需要使用的列。
6.查詢盡可能使用limit減少返回的行數，減少數據傳輸時間和帶寬浪費。
7.where子句盡可能對查詢列使用函數，因為對查詢列使用函數用不到索引。
8.避免隱式類型轉換，例如字符型一定要用’’，數字型一定不要使用’’。
9.所有的SQL關鍵詞用大寫，養成良好的習慣，避免SQL語句重復編譯造成系統資源的浪費。
10.聯表查詢的時候，記得把小結果集放在前面，遵循小結果集驅動大結果集的原則。
11.開啟慢查詢，定期用explain優化慢查詢中的SQL語句。
087 mysql是怎么備份的（重點）
一、備份的目的
做災難恢復：對損壞的數據進行恢復和還原
需求改變：因需求改變而需要把數據還原到改變以前
測試：測試新功能是否可用
二、備份需要考慮的問題
可以容忍丟失多長時間的數據；
恢復數據要在多長時間內完；
恢復的時候是否需要持續提供服務；
恢復的對象，是整個庫，多個表，還是單個庫，單個表。
三、備份的類型
1、根據是否需要數據庫離線
冷備（cold backup）：需要關mysql服務，讀寫請求均不允許狀態下進行；
溫備（warm backup）： 服務在線，但僅支持讀請求，不允許寫請求；
熱備（hot backup）：備份的同時，業務不受影響。
注：
1、這種類型的備份，取決於業務的需求，而不是備份工具
2、MyISAM不支持熱備，InnoDB支持熱備，但是需要專門的工具
2、根據要備份的數據集合的范圍
完全備份：full backup，備份全部字符集。
增量備份: incremental backup 上次完全備份或增量備份以來改變了的數據，不能單獨使用，要借助完全備份，備份的頻率取決於數據的更新頻率。
差異備份：differential backup 上次完全備份以來改變了的數據。
建議的恢復策略：
完全+增量+二進制日志
完全+差異+二進制日志
3、根據備份數據或文件
物理備份：直接備份數據文件
優點：備份和恢復操作都比較簡單，能夠跨mysql的版本，恢復速度快，屬於文件系統級別的
建議：不要假設備份一定可用，要測試mysql>check tables；檢測表是否可用
邏輯備份: 備份表中的數據和代碼
優點：恢復簡單、備份的結果為ASCII文件，可以編輯與存儲引擎無關可以通過網絡備份和恢復
缺點：備份或恢復都需要mysql服務器進程參與備份結果占據更多的空間，浮點數可能會丟失精度 還原之后，縮影需要重建
四：備份的對象
1、 數據；
2、配置文件；
3、代碼：存儲過程、存儲函數、觸發器
4、os相關的配置文件
5、復制相關的配置
6、二進制日志
五、備份和恢復的實現
1、利用select into outfile實現數據的備份與還原。
2、利用mysqldump工具對數據進行備份和還原
3、利用lvm快照實現幾乎熱備的數據備份與恢復
4、基於Xtrabackup做備份恢復。
優勢：
1、快速可靠的進行完全備份
2、在備份的過程中不會影響到事務
3、支持數據流、網絡傳輸、壓縮，所以它可以有效的節約磁盤資源和網絡帶寬。
4、可以自動備份校驗數據的可用性。
088 mysql 簡單的 怎么登入 怎么創建數據庫bbb創建 用戶 密碼 授權
一、創建用戶:
CREATE USER用於創建新的MySQL賬戶。要使用CREATE USER，您必須擁有mysql數據庫的全局CREATE USER權限，或擁有INSERT權限。對於每個賬戶，CREATE USER會在沒有權限的mysql.user表中創建一個新記錄。如果賬戶已經存在，則出現錯誤。
使用自選的IDENTIFIED BY子句，可以為賬戶給定一個密碼。user值和 密碼的給定方法和GRANT語句一 樣。特別是，要在純文本中指定密碼，需忽略PASSWORD關鍵詞。要把 密碼指定為由PASSWORD()函數返回的混編值，需包含關鍵字PASSWORD
The create user command:mysql> CREATE USER yy IDENTIFIED BY ‘123’;
面建立的用戶可以在任何地方登陸。
mysql> CREATE USER yy@localhost IDENTIFIED BY ‘123’;
二、授權:
命令:GRANT privileges ON databasename.tablename TO ‘username’@’host’
說明: privileges - 用戶的操作權限,如SELECT , INSERT , UPDATE 等.如果要授予所的權限則使
用 ALL.;databasename - 數據庫名,tablename-表名,如果要授予該用戶對所有數據庫和表的相應操
作權限則可用表示, 如.*.
GRANT SELECT, INSERT ON test.user TO ‘pig’@’%’;
GRANT ALL ON . TO ‘pig’@’%’;
注意:用以上命令授權的用戶不能給其它用戶授權,如果想讓該用戶可以授權,用以下命令:
GRANT privileges ON databasename.tablename TO ‘username’@’host’ WITH GRANT OPTION;
刷新系統權限表
flush privileges;
三、設置與更改用戶密碼
命令:SET PASSWORD FOR ‘username’@’host’ = PASSWORD(‘newpassword’);如果是當前登陸用戶用SET PASSWORD = PASSWORD(“newpassword”);
例子:SET PASSWORD FOR ‘pig’@’%’ = PASSWORD(“123456”);
或：update mysql.user set password=password(‘新密碼’) where User=”phplamp” and Host=”localhost”;
四、撤銷用戶權限
命令: REVOKE privilege ON databasename.tablename FROM ‘username’@’host’;
說明: privilege, databasename, tablename - 同授權部分.
例子: REVOKE SELECT ON . FROM ‘pig’@’%’;
注意: 假如你在給用戶’pig’@’%’授權的時候是這樣的(或類似的):GRANT SELECT ON test.user TO ‘pig’@’%’, 則在使用 REVOKE SELECT ON . FROM ‘pig’@’%’;命令並不能撤銷該用戶對test數據庫中user表的SELECT 操作.相反,如果授權使用的是GRANT SELECT ON . TO ‘pig’@’%’;則REVOKE SELECT ON test.user FROM ‘pig’@’%’;命令也不能撤銷該用戶對test數據庫中user表的Select 權限.具體信息可以用命令SHOW GRANTS FOR ‘pig’@’%’; 查看.
五、刪除用戶
命令: DROP USER ‘username’@’host’;
或：DELETE FROM user WHERE User=”phplamp” and Host=”localhost”;
//刪除用戶的數據庫
mysql>drop database phplampDB;
089 MySQL數據庫同步怎樣實現
1、安裝配置，兩台服務器，分別安裝好MySQL。采用單向同步的方式，就是Master的數據是主的數據，然后slave主動去Master哪兒同步數據回來。兩台服務器的配置一樣，把關鍵的配置文件拷貝一下，兩台服務器做相同的拷貝配置文件操作。
2、配置Master服務器，要考慮我們需要同步那個數據庫，使用那個用戶同步，我們這里為了簡單起見，就使用root用戶進行同步，並且只需要同步數據庫abc。
3、配置Slave服務器，我們的slave服務器主要是主動去Master服務器同步數據回來。
4、測試安裝，首先查看一下slave的主機日志：檢查是否連接正常， 在Master查看信息，查看Master狀態：查看Master下MySQL進程信息：在slave上查看信息：查看slave狀態：查看slave下MySQL進程信息：再在Master的abc庫里建立表結構並且插入數據，然后檢查slave有沒有同步這些數據，就能夠檢查出是否設置成功。
090 查詢mysql數據庫中用戶，密碼，權限的命令
查看MYSQL數據庫中所有用戶
SELECT DISTINCT CONCAT(‘User: ”’,user,”’@”’,host,”’;’) AS query FROM mysql.user;
查看數據庫中具體某個用戶的權限
show grants for ‘cactiuser’@’%’;
數據庫死鎖概念">091數據庫死鎖概念
多數情況下，可以認為如果一個資源被鎖定，它總會在以后某個時間被釋放。而死鎖發生在當多個進程訪問同一數據庫時，其中每個進程擁有的鎖都是其他進程所需的，由此造成每個進程都無法繼續下去。簡單的說，進程A等待進程B釋放他的資源，B又等待A釋放他的資源，這樣就互相等待就形成死鎖。
雖然進程在運行過程中，可能發生死鎖，但死鎖的發生也必須具備一定的條件，死鎖的發生必須具備以下四個必要條件。
1）互斥條件：指進程對所分配到的資源進行排它性使用，即在一段時間內某資源只由一個進程占用。如果此時還有其它進程請求資源，則請求者只能等待，直至占有資源的進程用畢釋放。
2）請求和保持條件：指進程已經保持至少一個資源，但又提出了新的資源請求，而該資源已被其它進程占有，此時請求進程阻塞，但又對自己已獲得的其它資源保持不放。
3）不剝奪條件：指進程已獲得的資源，在未使用完之前，不能被剝奪，只能在使用完時由自己釋放。
4）環路等待條件：指在發生死鎖時，必然存在一個進程——資源的環形鏈，即進程集合{P0，P1，P2，???，Pn}中的P0正在等待一個P1占用的資源；P1正在等待P2占用的資源，……，Pn正在等待已被P0占用的資源。
下列方法有助於最大限度地降低死鎖：
（1）按同一順序訪問對象。
（2）避免事務中的用戶交互。
（3）保持事務簡短並在一個批處理中。
（4）使用低隔離級別。
（5）使用綁定連接。
092 數據庫有幾種數據保護方式（AAA）
實現數據庫安全性控制的常用方法和技術有：用戶標識和鑒別；存取控制；視圖機制；審計；數據加密；
093 union和union all 的區別以及使用
Union因為要進行重復值掃描，所以效率低。如果合並沒有刻意要刪除重復行，那么就使用Union All兩個要聯合的SQL語句 字段個數必須一樣，而且字段類型要“相容”（一致）；
union和union all的區別是,union會自動壓縮多個結果集合中的重復結果，而union all則將所有的結果全部顯示出來，不管是不是重復。
Union：對兩個結果集進行並集操作，不包括重復行，同時進行默認規則的排序；
Union All：對兩個結果集進行並集操作，包括重復行，不進行排序；
Intersect：對兩個結果集進行交集操作，不包括重復行，同時進行默認規則的排序；
Minus：對兩個結果集進行差操作，不包括重復行，同時進行默認規則的排序。
可以在最后一個結果集中指定Order by子句改變排序方式。
mysql的備份命令是什么">094 mysql的備份命令是什么
mysqldump -hhostname -uusername -ppassword databasename > backupfile.sql
備份MySQL數據庫為帶刪除表的格式
備份MySQL數據庫為帶刪除表的格式，能夠讓該備份覆蓋已有數據庫而不需要手動刪除原有數據庫。
mysqldump -–add-drop-table -uusername -ppassword databasename > backupfile.sql
直接將MySQL數據庫壓縮備份
mysqldump -hhostname -uusername -ppassword databasename | gzip > backupfile.sql.gz
備份MySQL數據庫某個(些)表
mysqldump -hhostname -uusername -ppassword databasename specific_table1 specific_table2 > backupfile.sql
同時備份多個MySQL數據庫
mysqldump -hhostname -uusername -ppassword –databases databasename1 databasename2 databasename3 > multibackupfile.sql
僅僅備份數據庫結構
mysqldump –no-data –databases databasename1 databasename2 databasename3 > structurebackupfile.sql
備份服務器上所有數據庫
mysqldump –all-databases > allbackupfile.sql
還原MySQL數據庫的命令
mysql -hhostname -uusername -ppassword databasename < backupfile.sql
還原壓縮的MySQL數據庫
gunzip < backupfile.sql.gz | mysql -uusername -ppassword databasename
將數據庫轉移到新服務器
mysqldump -uusername -ppassword databasename | mysql –host=... -C databasename
095 在mysql服務器運行緩慢的情況下輸入什么命令能緩解服務器壓力
第一步 檢查系統的狀態
通過操作系統的一些工具檢查系統的狀態，比如CPU、內存、交換、磁盤的利用率，根據經驗或與系統正常時的狀態相比對，有時系統表面上看起來看空閑，這也可能不是一個正常的狀態，因為cpu可能正等待IO的完成。除此之外，還應觀注那些占用系統資源(cpu、內存)的進程。
1.1 使用sar來檢查操作系統是否存在IO問題
1.2 使用vmstat監控內存 cpu資源
1.3 磁盤IO問題，處理方式：做raid10提高性能
1.4 網絡問題，telnet一下MySQL對外開放的端口，如果不通的話，看看防火牆是否正確設置了。另外，看看MySQL是不是開啟了skip-networking的選項，如果開啟請關閉。
第二步 檢查mysql參數
2.1 max_connect_errors
2.2 connect_timeout
2.3 skip-name-resolve
2.4 slave-net-timeout=seconds
2.5 master-connect-retry
第三步 檢查mysql 相關狀態值
3.1 關注連接數
3.2 關注下系統鎖情況
3.3 關注慢查詢（slow query）日志
096 怎么導出表結構?
1.導出整個數據庫
mysqldump -u用戶名 -p密碼 數據庫名 > 導出的文件名
C:\Users\jack> mysqldump -uroot -pmysql sva_rec > e:\sva_rec.sql
2.導出一個表，包括表結構和數據
mysqldump -u用戶名 -p 密碼 數據庫名 表名> 導出的文件名
C:\Users\jack> mysqldump -uroot -pmysql sva_rec date_rec_drv> e:\date_rec_drv.sql
3.導出一個數據庫結構
C:\Users\jack> mysqldump -uroot -pmysql -d sva_rec > e:\sva_rec.sql
4.導出一個表，只有表結構
mysqldump -u用戶名 -p 密碼 -d數據庫名 表名> 導出的文件名
C:\Users\jack> mysqldump -uroot -pmysql -d sva_rec date_rec_drv> e:\date_rec_drv.sql
5.導入數據庫
常用source 命令
進入mysql數據庫控制台，
如mysql -u root -p
mysql>use 數據庫
然后使用source命令，后面參數為腳本文件(如這里用到的.sql)
mysql>source d:wcnc_db.sql
097 正常登入MYSQL后使用什么命令查看其進程是否正常
輸入show processlist;
如果有SUPER權限，則可以看到全部的線程，否則，只能看到自己發起的線程（這是指，當前對應的MySQL帳戶運行的線程）。
098 mysql遠程連接命令
一、MySQL 連接本地數據庫，用戶名為“root”，密碼“123”（注意：“-p”和“123” 之間不能有空格）
C:>mysql -h localhost -u root -p123
二、MySQL 連接遠程數據庫（192.168.0.201），端口“3306”，用戶名為“root”，密碼“123”
C:>mysql -h 192.168.0.201 -P 3306 -u root -p123
099 mysql主從用什么方式傳輸日志
MySQL 復制基於主服務器在二進制日志中跟蹤所有對數據庫的更改(更新、刪除等等)。每個從服務器從主服務器接收主服務器已經記錄到其二進制日志的保存的更新，以便從服務器可以對其數據拷貝執行相同的更新。
100 數據庫的備份方式
1、完全備份，這是大多數人常用的方式，它可以備份整個數據庫，包含用戶表、系統表、索引、視圖和存儲過程等所有數據庫對象。但它需要花費更多的時間和空間，所以，一般推薦一周做一次完全備份。
2、事務日志備份，事務日志是一個單獨的文件，它記錄數據庫的改變，備份的時候只需要復制自上次備份以來對數據庫所做的改變，所以只需要很少的時間。為了使數據庫具有魯棒性，推薦每小時甚至更頻繁的備份事務日志。
3、差異備份也叫增量備份。它是只備份數據庫一部分的另一種方法，它不使用事務日志，相反，它使用整個數據庫的一種新映象。它比最初的完全備份小，因為它只包含自上次完全備份以來所改變的數據庫。它的優點是存儲和恢復速度快。推薦每天做一次差異備份。
4、文件備份，數據庫可以由硬盤上的許多文件構成。如果這個數據庫非常大，並且一個晚上也不能將它備份完，那么可以使用文件備份每晚備份數據庫的一部分。由於一般情況下數據庫不會大到必須使用多個文件存儲，所以這種備份不是很常用。
101 查看mysql數據庫是否支持innodb
查看mysql的存儲引擎：show plugins;
如何在mysql某個表中隨機抽取10條記錄
1.通過MYSQL內置的函數來操作，具體SQL代碼如下：
SELECT * FROM tablename ORDER BY RAND() LIMIT 10
2.不要將大量的工作給數據庫去做，這樣會導致數據庫在某一集中並發時間內鎖死並阻塞。建議通過PHP隨機生成一下1-X(總行數)之間的數字，然后將這10個隨機數字作為查詢條件，具體語句如：
SELECT * FROM tablename where ID in (2,8,4,11,12,9,3,1,33)
可能你還要進行重復排除，並且需要在程序中將10個值串聯並連接進入SQL語句中。
102 如何查看連接mysql的當前用戶。
show full processlist，在user字段中查看有哪些用戶
103 寫出mysql怎么修改密碼?
方法一: (適用於管理員或者有全局權限的用戶重設其它用戶的密碼)
進入命令行模式
mysql -u root -p
mysql>use mysql;
mysql> UPDATE user SET password=PASSWORD(“new password”) WHERE user=’username’;
mysql> FLUSH PRIVILEGES;
mysql> quit;
方法二:
mysql -u root -p
mysql>use mysql;
mysql> SET PASSWORD FOR username=PASSWORD(‘new password’);
mysql> QUIT
方法三:
mysqladmin -u root “old password” “new password”
注：new password請輸入你想要設置的密碼。
104 MySQL怎么修復損壞的表?
有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。
105 簡單敘述一下MYSQL的優化（重點）
1.數據庫的設計：盡量把數據庫設計的更小的占磁盤空間.
1) 盡可能使用更小的整數類型.(mediumint就比int更合適).
2) 盡可能的定義字段為not null,除非這個字段需要null.
3) 如果沒有用到變長字段的話比如varchar,那就采用固定大小的紀錄格式比如char.
4) 表的主索引應該盡可能的短.這樣的話每條紀錄都有名字標志且更高效.
5) 只創建確實需要的索引。索引有利於檢索記錄，但是不利於快速保存記錄。如果總是要在表的組合字段上做搜索，那么就在這些字段上創建索引。索引的第一部分必須是最常使用的字段.如果總是需要用到很多字段，首先就應該多復制這些字段，使索引更好的壓縮。
6) 所有數據都得在保存到數據庫前進行處理。
7) 所有字段都得有默認值。
8) 在某些情況下,把一個頻繁掃描的表分成兩個速度會快好多。在對動態格式表掃描以取得相關記錄時，它可能使用更小的靜態格式表的情況下更是如此。
2.系統的用途
1) 盡量使用長連接.
2) explain復雜的SQL語句。
3) 如果兩個關聯表要做比較話，做比較的字段必須類型和長度都一致.
4) LIMIT語句盡量要跟order by或者 distinct.這樣可以避免做一次full table scan.
5) 如果想要清空表的所有紀錄,建議用truncate table tablename而不是delete from tablename.
6) 能使用STORE PROCEDURE 或者 USER FUNCTION的時候.
7) 在一條insert語句中采用多重紀錄插入格式.而且使用load data infile來導入大量數據，這比單純的insert快好多.
8) 經常OPTIMIZE TABLE 來整理碎片.
9) 還有就是date 類型的數據如果頻繁要做比較的話盡量保存在unsigned int 類型比較快。
3.系統的瓶頸
1) 磁盤搜索。並行搜索,把數據分開存放到多個磁盤中，這樣能加快搜索時間.
2) 磁盤讀寫(IO)。可以從多個媒介中並行的讀取數據。
3) CPU周期。數據存放在主內存中.這樣就得增加CPU的個數來處理這些數據。
4) 內存帶寬。當CPU要將更多的數據存放到CPU的緩存中來的話,內存的帶寬就成了瓶頸.
106 如何確定有哪些存儲引擎可用？
mysql> show engines; 顯示了可用的數據庫引擎的全部名單以及在當前的數據庫服務器中是否支持這些引擎。
107 MYSQL數據庫設計數據類型選擇需要注意哪些地方?（重點）
VARCHAR和CHAR類型，varchar是變長的，需要額外的1-2個字節存儲，能節約空間，可能會對性能有幫助。但由於是變長，可能發生碎片，如更新數據；
使用ENUM代替字符串類型，數據實際存儲為整型。
字符串類型
要盡可能地避免使用字符串來做標識符，因為它們占用了很多空間並且通常比整數類型要慢。特別注意不要在MYISAM表上使用字符串標識符。MYISAM默認情況下為字符串使用了壓縮索引（Packed Index），這使查找更為緩慢。據測試，使用了壓縮索引的MYISAM表性能要慢6倍。
還要特別注意完全‘隨機’的字符串，例如由MD5（）、SHA1（）、UUID（）產生的。它們產生的每一個新值都會被任意地保存在很大的空間范圍內，這會減慢INSERT及一些SELECT查詢。
1）它們會減慢INSERT查詢，因為插入的值會被隨機地放入索引中。這會導致分頁、隨機磁盤訪問及聚集存儲引擎上的聚集索引碎片。
2)它們會減慢SELECT查詢，因為邏輯上相鄰的行會分布在磁盤和內存中的各個地方。
3）隨機值導致緩存對所有類型的查詢性能都很差，因為它們會使緩存賴以工作的訪問局部性失效。如果整個數據集都變得同樣“熱”的時候，那么把特定部分的數據緩存到內存中就沒有任何的優勢了。並且如果工作集不能被裝入內存中，緩存就會進行很多刷寫的工作，並且會導致很多緩存未命中。
如果保存UUID值，就應該移除其中的短橫線，更好的辦法是使用UHEX（）把UUID值轉化為16字節的數字，並把它保存在BINARY（16）列中。
108 mysql、oracle默認端口號
3306、1521
109 innodb的事務與日志的實現方式。
（1）有多少種日志
錯誤日志：記錄出錯信息，也記錄一些警告信息或者正確的信息
慢查詢日志：設置一個閾值，將運行時間超過該值的所有SQL語句都記錄到慢查詢的日志文件中。
二進制日志：記錄對數據庫執行更改的所有操作
查詢日志：記錄所有對數據庫請求的信息，不論這些請求是否得到了正確的執行。
（2）日志的存放形式
（3）事務是如何通過日志來實現的，說得越深入越好。
在Innodb存儲引擎中，事務日志是通過redo和innodb的存儲引擎日志緩沖（Innodb log buffer）來實現 的，當開始一個事務的時候，會記錄該事務的lsn(log sequence number)號; 當事務執行時，會往InnoDB存 儲引擎的日志的日志緩存里面插入事務日志；當事務提交時，必須將存儲引擎的日志緩沖寫入磁盤（通過 innodb_flush_log_at_trx_commit來控制），也就是寫數據前，需要先寫日志。這種方式稱為“預寫日志方 式”， innodb通過此方式來保證事務的完整性。也就意味着磁盤上存儲的數據頁和內存緩沖池上面的頁是不同步 的，是先寫入redo log，然后寫入data file，因此是一種異步的方式。
隔離性： 通過鎖實現
原子性、一致性和持久性是通過redo和undo來完成的。