㈠ 資料庫系統方面的問題,求最小函數依賴集、候選碼、分解滿足範式的關系模式
1.F={A->B,C->D,AE->F，F->G}已經是F的最小函數依賴集
2.R的候選碼：ACE
3.R分解為：R1(A，B，C，D，E)和R2(F,G)均滿足BCNF範式
㈡ 進入IT企業必讀的200個 .NET面試題的目 錄
第1章 應聘開發職位的技巧和禁忌 1
程序員在准備面試的過程中，有時會過分注重技術上的准備工作，事實上，一些非技術的准備工作也相當重要。掌握好應聘技術職位過程中的軟技巧、准備一份出色的簡歷、提高警惕避免在應聘中觸犯一些禁忌，可以大大地提高面試的成功率。在開始面試時，還要把握一些強勢的招聘網站，給自己一個展現自我的平台。本章從了解、准備、開始，層層漸進，讓讀者對整個程序員面試的過程有個全局性的掌握。
1.1 技術職位需要怎樣的人才——了解大環境 1
1.1.1 對技術的執著和熱情 1
1.1.2 對編程始終抱有認真的態度 1
1.1.3 實事求是的態度和謙遜的品質 1
1.1.4 適合應聘公司的文化 1
1.2 一份出色的個人簡歷——面試准備 2
1.2.1 一份簡歷不宜超過一頁 2
1.2.2 永遠准備中文簡歷 2
1.2.3 不要在個人簡歷上註明希望薪水 2
1.2.4 簡歷模板 2
1.3 展現自我——開始發簡歷 3
1.3.1 應聘渠道 3
1.3.2 應聘流程 7
1.4 真正的面試——開始面試 8
1.4.1 筆試 8
1.4.2 面試 10
1.4.3 電話面試 10
1.4.4 網路考試 10
1.5 面試中的一些禁忌 11
1.6 小結 12
第2章 .NET框架基礎 13
本章覆蓋了.NET面試筆試中常見的.NET框架技術題。此類題目側重於考查應聘者對於.NET機制的深入了解，徹底理解.NET的運行機制，並且熟悉一個.NET系統常用的管理部署方法。
2.1 .NET基礎概念 13
2.1.1 什麼是CTS、CLS和CLR 13
2.1.2 開發和運行.NET程序需要的
最基本環境是什麼 15
2.1.3 .NET是否支持多編程語言開發 15
2.1.4 CLR技術和COM技術的比較 17
2.1.5 什麼是程序集和應用程序域 18
2.2 .NET運行機制 20
2.2.1 .NET程序被編譯成什麼形式的代碼 20
2.2.2 JIT是如何工作的 22
2.2.3 簡述程序集的載入機制 23
2.2.4 如何配置程序集的版本策略 25
2.3 生成、部署和管理 27
2.3.1 如何生成強簽名的程序集 27
2.3.2 如何把程序集放入GAC中 29
2.3.3 延遲簽名及其作用 30
2.3.4 程序集的版本分哪幾部分 32
2.4 名企面試真題 32
2.5 小結 33
第3章 .NET類型語法基礎 34
本章覆蓋了.NET面試筆試中最基礎的語法和類型題。縱觀.NET的面試題，此類題目涉及了最基礎的知識點，其難度也相對最小。但是應聘者如果對此類的面試題回答得不正確或者不完整，將會給面試官留下技術水平較差的印象，建議讀者對本章的題目做到深刻理解和掌握。
3.1 基礎類型和語法 34
3.1.1 .NET中所有內建類型的基類是什麼 34
3.1.2 System.Object中包含哪些方法，哪些是虛方法 35
3.1.3 值類型和引用類型的區別 37
3.1.4 簡述裝箱和拆箱原理 40
3.1.5 C#中是否有全局變數 43
3.1.6 struct和class的區別，
struct適用哪些場合 43
3.1.7 類型的初始化器何時被調用 44
3.1.8 C#中方法的參數可以有哪幾種傳遞方式 47
3.1.9 C#中string和String有什麼區別 50
3.1.10 .NET支持哪幾種可訪問性級別，C#實現了其中的哪幾種 50
3.1.11 簡述屬性的特點及屬性和方法的異同 51
3.1.12 簡述C#中的淺復制和深復制 54
3.1.13 簡述C#中的循環語法和各自的特點 57
3.1.14 C#中的using語句有什麼作用 60
3.2 內存管理和垃圾回收 62
3.2.1 簡述.NET中堆棧和堆的特點和差異 62
3.2.2 執行string abc=aaa+bbb+ccc共分配了多少內存 64
3.2.3 .NET中GC的運行機制 66
3.2.4 Dispose方法和Finalize方法在何時被調用 67
3.2.5 GC中代（Generation）是什麼，一共分幾代 70
3.2.6 GC機制中如何判斷一個對象是否仍在被使用 71
3.2.7 .NET的託管堆中是否可能出現內存泄漏現象 72
3.3 面向對象的實現 75
3.3.1 C#中類可以有多個父類、可以實現多個介面嗎 75
3.3.2 簡述C#中重寫、重載和隱藏的概念 76
3.3.3 為什麼在構造方法中調用虛方法會導致問題 78
3.3.4 在C#中如何聲明一個類不能被繼承 82
3.4 異常的處理 82
3.4.1 如何針對不同的異常進行捕捉 82
3.4.2 如何使用Conditional特性 84
3.4.3 如何避免類型轉換時的異常 86
3.5 名企面試真題 88
3.6 小結 89
第4章 字元串、集合和流的使用 90
字元串、集合和流在程序中處理數據時經常被用到，這些代碼的編寫將直接影響到系統的正確性和效率。本章將包含關於字元串、集合和流的常見面試題，並且通過分析這些題目和知識點，幫助讀者梳理這些方面的知識。
4.1 字元串處理 90
4.1.1 System.String是值類型還是引用類型 90
4.1.2 StringBuilder類型有何作用 91
4.1.3 如何在String和Byte[]對象之間進行轉換 92
4.1.4 簡述BASE64編碼的作用以及C#中對其的支持 94
4.1.5 SecureString的實例如何被分配和釋放 96
4.1.6 什麼是字元串池機制 98
4.2 常用集合和泛型 99
4.2.1 Int[]是引用類型還是值類型 99
4.2.2 數組之間如何進行轉換 100
4.2.3 解釋泛型的基本原理 102
4.2.4 什麼是泛型的主要約束和次要約束 104
4.2.5 .NET中是否可用標准模板庫（STL） 105
4.3 流和序列化 106
4.3.1 什麼是流，.NET中有哪些常見的流 106
4.3.2 如何使用壓縮流 109
4.3.3 Serializable特性有何作用 111
4.3.4 .NET提供了哪幾種可進行序列化操作的類型 113
4.3.5 如何自定義序列化和反序
列化的過程 116
4.4 名企面試真題 119
4.5 小結 119
第5章 常用類和介面 120
.NET除了提供運行引擎之外，還提供了豐富的內建類型。理解這些類型的作用和機制，能夠幫助程序員減少代碼工作，編寫高效簡潔的代碼。而有時候誤用類型，則會導致性能的降低，更嚴重時則會為系統帶了潛伏的bug。本章將介紹一些經常出現在.NET面試中的類型和介面。
5.1 類型的基類System.Object 120
5.1.1 是否存在不繼承自System.Object類型的類 120
5.1.2 在System.Object中定義的三個比較方法有何異同 122
5.1.3 如何重寫GetHashCode方法 125
5.2 時間的操作System.DateTime 127
5.2.1 DateTime如何存儲時間 127
5.2.2 如何在DateTime對象和
字元串對象之間進行轉換 127
5.2.3 什麼是UTC時間，如何轉換到UTC時間 130
5.3 IFormattable和IformatProvider的使用 131
5.3.1 如何使用IFormattable介面實現格式化輸出 131
5.3.2 如何告訴類型格式化輸出的方式 133
5.4 管理文件和文件夾的類型 135
5.4.1 如何操作文件和文件夾 135
5.4.2 如何實現文件和文件夾的監控功能 139
5.5 .NET中的定時器 141
5.5.1 .NET提供了哪幾個定時器類型 141
5.5.2 .NET的內建定時器類型
是否會發生回調方法重入 146
5.6 名企面試真題 151
5.7 小結 151
第6章 .NET中的高級特性 152
本章的內容覆蓋了諸如委託、事件、反射和特性等.NET框架中的高級特性。對這些特性的掌握和成熟運用，往往成為.NET程序員從入門級進階到中級的判斷標准。也正因為如此，此類題目在.NET技術筆試、面試中被大量採用。讀者在閱讀本章時，應力求做到知其然更知其所以然，充分理解各種特性在.NET框架下是如何實現的，這樣的設計如何提高了程序的靈活性和可擴展性。
6.1 委託 152
6.1.1 請解釋委託的基本原理 152
6.1.2 委託回調靜態方法和實例方法有何區別 154
6.1.3 什麼是鏈式委託 154
6.1.4 鏈式委託的執行順序是怎麼樣的 156
6.1.5 可否定義擁有返回值的方法的委託鏈 157
6.1.6 委託通常可以應用在哪些場合 159
6.2 事件 165
6.2.1 請解釋事件的基本使用方法 165
6.2.2 事件和委託有何聯系 167
6.2.3 如何設計一個帶有很多事件的類型 169
6.2.4 用代碼表示如下情景：貓叫、老鼠逃跑、主人驚醒 173
6.3 反射 175
6.3.1 請解釋反射的基本原理和其實現的基石 176
6.3.2 .NET提供了哪些類型來實現反射 179
6.3.3 如何實現動態地發射程序集 184
6.3.4 如何利用反射來實現工廠模式 188
6.3.5 如何以較小的內存代價保存
Type、Field和Method信息 194
6.4 特性 196
6.4.1 什麼是特性，如何自定義一個特性 196
6.4.2 .NET中特性可以在哪些元素上使用 198
6.4.3 有哪幾種方法可以獲知一個元素是否申明某個特性 200
6.4.4 一個元素是否可以重復申明同一個特性 202
6.5 名企面試真題 204
6.6 小結 204
第7章 .NET多線程編程 205
多線程編程是每個技術框架下都需要面對的問題，在多CPU、多核的硬體架構逐漸普及的今天，多線程編程也漸漸變得更加重要。本章將集中覆蓋關於.NET中多線程編程的面試題。
7.1 多線程編程的基本概念 205
7.1.1 請解釋操作系統層面上的線程和進程 205
7.1.2 多線程程序在操作系統里是並行執行的嗎 206
7.1.3 什麼是纖程 207
7.2 .NET中的多線程編程 208
7.2.1 如何在.NET程序中手動控制多個線程 208
7.2.2 如何使用.NET的線程池 212
7.2.3 如何查看和設置線程池的上下限 215
7.2.4 如何定義線程獨享的全局數據 217
7.2.5 如何使用非同步模式讀取一個文件 221
7.2.6 如何阻止線程執行上下文的傳遞 223
7.3 多線程程序的線程同步 227
7.3.1 什麼是同步塊和同步塊索引 227
7.3.2 C#中的lock關鍵字有何作用 229
7.3.3 可否使用值類型對象來
實現線程同步 232
7.3.4 可否對引用類型對象自身進行同步 233
7.3.5 什麼是互斥體，Mutex類型和Monitor類型的功能有何區別 235
7.4 名企面試真題 238
7.5 小結 238
第8章 ASP NET應用開發 239
ASP NET是微軟公司提供的編寫動態網站的技術框架，其特點是基於.NET框架基礎，所有ASP NET程序都可以使用針對.NET的語言編寫。在微軟公司的Visual Studio開發平台中，實現了拖放控制項等便捷的功能，使得ASP NET應用程序的開發效率得到了較大的提高，近些年來ASP NET技術逐漸成為網站開發的主流技術之一，本章將覆蓋一些常見的關於ASP NET開發的面試題。
8.1 ASP NET應用開發基礎 239
8.1.1 請解釋ASP NET以什麼形式運行 239
8.1.2 常見的HTTP Code有哪些 242
8.1.3 GET請求和POST請求有何區別 245
8.1.4 介紹ASP NET的頁面生存周期 247
8.2 控制項和頁面 249
8.2.1 什麼是靜態頁面，什麼是動態頁面 250
8.2.2 請簡述ViewState的功能和實現機制 251
8.2.3 Session有哪幾種存儲方式，之間有何區別，如何進行設置 255
8.2.4 如何嵌套使用GridView控制項 259
8.2.5 列舉幾種實現頁面跳轉的方法，並說明其實現機制 263
8.2.6 請解釋<%# Eval（source）%>的功能和實現機制 270
8.2.7 ObjectDataSource控制項有何作用 273
8.3 驗證和安全 277
8.3.1 如何使用正則表達式來驗證一個
上海市電話號碼 277
8.3.2 介紹ASP NET驗證控制項的功能和
使用方法 280
8.3.3 如何防止sql注入式攻擊 287
8.4 名企面試真題 289
8.5 小結 289
第9章 .NET中的資料庫開發 290
大部分系統都會包含資料庫應用。資料庫應用設計往往成為系統設計中最重要的組成之一，這其中不止包括資料庫的架構、庫結構的設計，也包括了程序訪問資料庫策略的設計。在.NET的程序開發中，ADO NET已經成為訪問資料庫最主要的組件框架。本章將覆蓋和資料庫訪問及ADO NET有關的常見面試題，具體會覆蓋ADO NET基本概念、資料庫的鏈接、資料庫讀寫等主題。
9.1 ADO NET和資料庫程序基礎 290
9.1.1 什麼是關系型資料庫 290
9.1.2 如何通過SQL語句來實現行列轉換 291
9.1.3 ADO NET支持哪幾種數據源 293
9.2 ADO NET和資料庫的連接 295
9.2.1 請簡要敘述資料庫連接池的機制 295
9.2.2 如何提高連接池內連接的重用率 298
9.2.3 一個連接字元串可以包含哪些屬性 300
9.2.4 CommandBehavior.CloseConnection有何作用 302
9.3 使用ADO NET讀寫資料庫 305
9.3.1 ADO NET支持哪兩種方式來訪問關系資料庫 305
9.3.2 什麼是強類型的DataSet 309
9.3.3 請解釋SqlDataAdapter的
基本工作機制 312
9.3.4 如何自動生成SqlDataAdapter的
更新命令 316
9.3.5 如何實現批量更新的功能 319
9.4 名企面試真題 321
9.5 小結 321
第10章 XML的應用和處理 322
XML可算是近10年來最炙手可熱的技術之一，由於其跨平台的特性，很多技術應用都選擇基於XML來進行發展。在.NET中，對XML的支持和應用隨處可見。例如配置文件的格式、數據結構的表示、Web Service應用等，都是以XML語法為基礎的。本章將詳細覆蓋常見的關於XML本身及其在.NET中應用的面試題。
10.1 XML的基本特性 322
10.1.1 什麼是XML 322
10.1.2 簡述XML的常用領域及其優勢 323
10.1.3 XML中<![CDATA[ ]]>標簽的作用 324
10.1.4 XML規范是否允許空的屬性值 325
10.1.5 XML中如何處理諸如「<」的字元 326
10.1.6 XML中的命名空間如何使用 328
10.2 使用.NET組件讀寫XML 330
10.2.1 .NET中操作XML的基本類型有哪些 330
10.2.2 如何使用XmlDocument類型操作XML文檔的節點和屬性 334
10.2.3 如何使用XPath來指向帶有屬性的節點 337
10.2.4 .NET中如何驗證一個XML文檔的格式 338
10.2.5 .NET中XML文檔和關系模式如何轉換 340
10.3 利用XSLT處理XML文檔 344
10.3.1 什麼是XSLT，XSLT有何作用 344
10.3.2 如何使用XSLT中的模板 346
10.3.3 如何在XSLT文檔中調用
其他XSLT文檔 349
10.3.4 如何在代碼中使用XSLT文檔 351
10.4 名企面試真題 353
10.5 小結 353
第11章 Web Service的開發與應用 354
Web Service是一種網路服務，形式非常類似於當前智能手機上的應用。通過通用的規范，Web Service技術允許使用者訪問網路上每一個Web Service所提供的服務。在網路快速發展的今天，這種基於網路的分布式服務已經被廣泛地應用。本章將討論關於.NET中如何應用Web Service的面試題。
11.1 SOAP和Web Service的基礎概念 354
11.1.1 請簡述SOAP協議 354
11.1.2 什麼是WSDL，它有何作用 356
11.1.3 Web Service中如何處理附件 357
11.2 使用.NET開發Web Service 360
11.2.1 如何在.NET中創建Web Service 360
11.2.2 WebMethod特性包含哪些屬性，各有何用處 363
11.2.3 如何生成Web Service代理類型 367
11.2.4 請簡述.NET中Web Service的異常機制 368
11.3 Web Service的安全機制 371
11.3.1 請簡要介紹WS-Security的簽名機制 371
11.3.2 WS-Security規范申明了哪幾種身份驗證的方法 373
11.4 名企面試真題 375
11.5 小結 375
第12章 .NET Remoting分布式應用開發 376
在企業級應用開發中，分布式開發占據了越來越重要的地位。.NET Remoting是一種可擴展性很高的分布式開發技術，相對於DCOM、CORBA、RMI等分布式開發技術而言，.NET Remoting擁有著眾多獨特的優勢。.NET Remoting是一個龐大的技術話題，如果詳細展開的話可能要佔據一本書的篇幅。本章主要針對那些經常出現在.NET面試中的、與Remoting基礎相關的面試題。
12.1 .NET Remoting框架基礎 376
12.1.1 請簡要介紹.NET Remoting的運行機制 376
12.1.2 請列舉.NET Remoting機制中有哪些組件可以擴展替換 379
12.1.3 請簡述.NET Remoting生存周期機制 384
12.2 使用.NET Remoting進行分布式應用開發 387
12.2.1 請介紹服務端激活模式和客戶端激活模式的區別 387
12.2.2 請簡述Remoting中有哪幾種遠程調用方式 390
12.2.3 Remoting機制中如何處理以ObjRef為參數的方法調用 393
12.2.4 請簡述Remoting中配置文件的使用 397
12.2.5 如何在客戶端和伺服器端共享遠程對象類型 400
12.3 名企面試真題 404
12.4 小結 404
第13章 代碼和演算法 405
無論是面試還是筆試，演算法和代碼的問題都是必不可少的，其區別僅在於筆試中更側重於應聘者書寫代碼的能力，而面試中則更注重於應聘者的設計能力和演算法思路。本章著重覆蓋了一些在.NET面試中經常出現的和代碼、演算法有關的面試題，並且給出了解答思路和實現示例。
13.1 基礎演算法題 405
13.1.1 請實現一個快速排序演算法 405
13.1.2 請實現一個二分查找演算法 406
13.1.3 請實現一棵二叉樹的中序、後序遍歷 408
13.1.4 請寫出一個奇偶分割演算法 413
13.1.5 請實現一個簡單的最短路徑演算法 414
13.2 程序設計題 423
13.2.1 請編程實現斐波拉契數列問題 423
13.2.2 請設計窗口程序演示八皇後問題 425
13.3 名企面試真題 432
13.4 小結 432
第14章 .NET中的單元測試 433
單元測試是軟體開發中必不可少的一個環節，單元測試的優劣直接影響到集成測試、系統測試的效果，甚至會影響到最終產品的質量。大多數開發團隊對單元測試非常重視，並且要求程序員掌握相應的知識。本章將覆蓋在.NET面試中經常出現的關於單元測試的面試題。
14.1 單元測試基礎概念 433
14.1.1 請簡述單元測試的作用和其優點 433
14.1.2 請舉例說明TDD開發方式的流程 434
14.1.3 請編寫實現階乘功能模塊的測試用例 437
14.2 使用NUNIT進行單元測試 439
14.2.1 如何使用NUNIT來進行單元測試 439
14.2.2 如何對NUNIT的測試用例進行分類 442
14.2.3 請解釋SetUp、TearDown、TestFixtureSetUp和
TestFixtureTearDown 446
14.3 名企面試真題 448
14.4 小結 448
㈢ 關系資料庫設計問題：考慮如下關系模式r(A,B,C,D,E,F) 上的函數依賴集F：A->BCD BC->DE B->D D->A
資料庫的。
那活動
好的
㈣ MYSQL資料庫索引類型都有哪些
在滿足語句需求的情況下，盡量少的訪問資源是資料庫設計的重要原則，這和執行的 SQL 有直接的關系，索引問題又是 SQL 問題中出現頻率最高的，常見的索引問題包括：無索引（失效）、隱式轉換。
1. SQL 執行流程看一個問題，在下面這個表 T 中，如果我要執行 select * from T where k between 3 and 5; 需要執行幾次樹的搜索操作，會掃描多少行？mysql> create table T ( -> ID int primary key, -> k int NOT NULL DEFAULT 0, -> s varchar(16) NOT NULL DEFAULT '', -> index k(k)) -> engine=InnoDB;mysql> insert into T values(100,1, 'aa'),(200,2,'bb'), (300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');
這分別是 ID 欄位索引樹、k 欄位索引樹。
這條 SQL 語句的執行流程：
1. 在 k 索引樹上找到 k=3，獲得 ID=3002. 回表到 ID 索引樹查找 ID=300 的記錄，對應 R33. 在 k 索引樹找到下一個值 k=5，ID=5004. 再回到 ID 索引樹找到對應 ID=500 的 R4
5. 在 k 索引樹去下一個值 k=6，不符合條件，循環結束
這個過程讀取了 k 索引樹的三條記錄，回表了兩次。因為查詢結果所需要的數據只在主鍵索引上有，所以必須得回表。所以，我們該如何通過優化索引，來避免回表呢？
2. 常見索引優化2.1 覆蓋索引覆蓋索引，換言之就是索引要覆蓋我們的查詢請求，無需回表。
如果執行的語句是 select ID from T wherek between 3 and 5;，這樣的話因為 ID 的值在 k 索引樹上，就不需要回表了。
覆蓋索引可以減少樹的搜索次數，顯著提升查詢性能，是常用的性能優化手段。
但是，維護索引是有代價的，所以在建立冗餘索引來支持覆蓋索引時要權衡利弊。
2.2 最左前綴原則
B+ 樹的數據項是復合的數據結構，比如 (name,sex，age) 的時候，B+ 樹是按照從左到右的順序來建立搜索樹的，當 (張三,F,26) 這樣的數據來檢索的時候，B+ 樹會優先比較 name 來確定下一步的檢索方向，如果 name 相同再依次比較 sex 和 age，最後得到檢索的數據。
# 有這樣一個表 P
mysql> create table P (id int primary key, name varchar(10) not null, sex varchar(1), age int, index tl(name,sex,age)) engine=IInnoDB;
mysql> insert into P values(1,'張三','F',26),(2,'張三','M',27),(3,'李四','F',28),(4,'烏茲','F',22),(5,'張三','M',21),(6,'王五','M',28);
# 下面的語句結果相同
mysql> select * from P where name='張三' and sex='F'; ## A1
mysql> select * from P where sex='F' and age=26; ## A2
# explain 看一下
mysql> explain select * from P where name='張三' and sex='F';
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
| 1 | SIMPLE | P | NULL | ref | tl | tl | 38 | const,const | 1 | 100.00 | Using index |
+----+-------------+-------+------------+------+---------------+------+---------+-------------+------+----------+-------------+
mysql> explain select * from P where sex='F' and age=26;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
| 1 | SIMPLE | P | NULL | index | NULL | tl | 43 | NULL | 6 | 16.67 | Using where; Using index |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+--------------------------+
- 可以清楚的看到，A1 使用 tl 索引，A2 進行了全表掃描，雖然 A2 的兩個條件都在 tl 索引中出現，但是沒有使用到 name 列，不符合最左前綴原則，無法使用索引。所以在建立聯合索引的時候，如何安排索引內的欄位排序是關鍵。評估標準是索引的復用能力，因為支持最左前綴，所以當建立（a，b）這個聯合索引之後，就不需要給 a 單獨建立索引。原則上，如果通過調整順序，可以少維護一個索引，那麼這個順序往往就是需要優先考慮採用的。上面這個例子中，如果查詢條件里只有 b，就是沒法利用（a，b）這個聯合索引的，這時候就不得不維護另一個索引，也就是說要同時維護（a，b）、（b）兩個索引。這樣的話，就需要考慮空間佔用了，比如，name 和 age 的聯合索引，name 欄位比 age 欄位佔用空間大，所以創建（name，age）聯合索引和（age）索引佔用空間是要小於（age，name）、(name）索引的。
- 以人員表的聯合索引（name, age）為例。如果現在有一個需求：檢索出表中「名字第一個字是張，而且年齡是26歲的所有男性」。那麼，SQL 語句是這么寫的mysql> select * from tuser where name like '張%' and age=26 and sex=M;
- 通過最左前綴索引規則，會找到 ID1，然後需要判斷其他條件是否滿足在 MySQL 5.6 之前，只能從 ID1 開始一個個回表。到主鍵索引上找出數據行，再對比欄位值。而 MySQL 5.6 引入的索引下推優化(index condition pushdown)，可以在索引遍歷過程中，對索引中包含的欄位先做判斷，直接過濾掉不滿足條件的記錄，減少回表次數。這樣，減少了回表次數和之後再次過濾的工作量，明顯提高檢索速度。
- 隱式類型轉化主要原因是，表結構中指定的數據類型與傳入的數據類型不同，導致索引無法使用。所以有兩種方案：
- 修改表結構，修改欄位數據類型。
修改應用，將應用中傳入的字元類型改為與表結構相同類型。
- 3. 為什麼會選錯索引3.1 優化器選擇索引是優化器的工作，其目的是找到一個最優的執行方案，用最小的代價去執行語句。在資料庫中，掃描行數是影響執行代價的因素之一。掃描的行數越少，意味著訪問磁碟數據的次數越少，消耗的 CPU 資源越少。當然，掃描行數並不是唯一的判斷標准，優化器還會結合是否使用臨時表、是否排序等因素進行綜合判斷。
- MySQL 在真正開始執行語句之前，並不能精確的知道滿足這個條件的記錄有多少條，只能通過索引的區分度來判斷。顯然，一個索引上不同的值越多，索引的區分度就越好，而一個索引上不同值的個數我們稱為「基數」，也就是說，這個基數越大，索引的區分度越好。# 通過 show index 方法，查看索引的基數mysql> show index from t;+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+| t | 0 | PRIMARY | 1 | id | A | 95636 | NULL | NULL | | BTREE | | || t | 1 | a | 1 | a | A | 96436 | NULL | NULL | YES | BTREE | | || t | 1 | b | 1 | b | A | 96436 | NULL | NULL | YES | BTREE | | |+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
- MySQL 使用采樣統計方法來估算基數：采樣統計的時候，InnoDB 默認會選擇 N 個數據頁，統計這些頁面上的不同值，得到一個平均值，然後乘以這個索引的頁面數，就得到了這個索引的基數。而數據表是會持續更新的，索引統計信息也不會固定不變。所以，當變更的數據行數超過 1/M 的時候，會自動觸發重新做一次索引統計。
on 表示統計信息會持久化存儲。默認 N = 20，M = 10。
off 表示統計信息只存儲在內存中。默認 N = 8，M = 16。
- 由於是采樣統計，所以不管 N 是 20 還是 8，這個基數都很容易不準確。所以，冤有頭債有主，MySQL 選錯索引，還得歸咎到沒能准確地判斷出掃描行數。
- ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...
- 3.3 索引選擇異常和處理1. 採用 force index 強行選擇一個索引。2. 可以考慮修改語句，引導 MySQL 使用我們期望的索引。3. 有些場景下，可以新建一個更合適的索引，來提供給優化器做選擇，或刪掉誤用的索引。
2.3 索引下推
2.4 隱式類型轉化
3.2 掃描行數
在 MySQL 中，有兩種存儲索引統計的方式，可以通過設置參數 innodb_stats_persistent 的值來選擇：
可以用 analyze table 來重新統計索引信息，進行修正。
㈤ 測試工程師面試，介面測試問題總結
1、什麼是介面？
2、什麼是介面測試？
3、介面組成的要素有哪些？
4、Python 的 requests 包是干什麼的？
5、如何使用 Python 的 requests 包？
6、為什麼開展介面測試？
7、為什麼要寫介面測試用例？
8、介面測試用例設計主要考慮哪些？
9、介面測試用例包含哪些內容？
10、介面測試如何設計用例？
11、通用介面用例設計？
12、介面測試報告包含哪些內容？
13、測試指標范圍包含哪些？
14、做介面測試運用過哪些測試工具？
15、抓包工具用過哪些？
16、為什麼進行抓包測試？
17、TCP/IP 參考模型有哪幾層？
18、常用協議的埠號？
19、常見的狀態碼有哪些？
20、你們公司的介面測試流程是怎樣的？
21、請詳細闡述介面測試和 UI 測試在測試活動中是如何協同測試的？
22、介面測試注意事項？
23、介面測試執行中對比資料庫嗎？
24、請簡述一下 cookie、session 以及 token 的區別？
25、談談你對 HTTP 協議的了解？
26、你對 http 請求跟 webservice 請求的了解？
27、在介面測試中關聯是什麼含義？如何使用 Postman 設置關聯？
28、介面自動化測試框架一般分為幾層？
29、測試框架里如何做到數據和代碼分離？
1、什麼是介面？
介面就是 API，意思是應用程序編程介面。
介面本質上是程序開發的函數和方法，提供參數和返回值。
2、什麼是介面測試？
介面測試是測試系統組件間介面的一種測試，介面測試主要用於檢測外部系統和內部系統之間以及各個子系統之間的交互點。測試的重點是檢查數據的交換、傳遞和控制管理的過程，以及系統間的相互邏輯依賴關系等。
3、介面組成的要素有哪些？
介面訪問的地址、請求的方法、參數、返回值
（1）介面訪問的地址 協議://IP 地址或域名:埠號/應用名/功能名
（2）請求的方法 get、post 等
（3）參數 用戶使用介面時，需要向介面提供的數據。
（4）返回值 介面給用戶的反饋結果。
4、Python 的 requests 包是干什麼的？
requests 是一個 HTTP 庫，作用是發送 HTTP 請求，獲得響應，往往使用在網路爬蟲，介面自動化測試中。
5、如何使用 Python 的 requests 包？
（1）安裝 Python
（2）安裝 requests 模塊
（3）創建.py 文件
（4）導入 requests 模塊
（5）編寫 Python 代碼
（6）調用 requests 方法
6、為什麼開展介面測試？
介面測試屬於集成測試、測試接入越早，就越能在項目早期發現問題，修復問題成本降低。
介面測試非常快速，UI 自動化執行一個測試用例 10s 左右，介面用例執行一般毫秒級。
7、為什麼要寫介面測試用例？
（1）理清思路，避免漏測和重復測試。
（2）提高測試效率、跟進測試進度、告訴領導做過、跟進重復性工作。
（3）更好的記錄問題、發現問題、復現問題、同時這也是介面測試流程中的一個產物。
8、介面測試用例設計主要考慮哪些？
（1）功能是否正常。
（2）功能是否按照介面文檔實現、是否依賴業務、異常情況（參數異常、數據異常）、安全測試等。
9、介面測試用例包含哪些內容？
用例名稱、介面地址、請求方式、前置條件、描述、請求頭部、請求參數、狀態碼、預期返回結果
10、介面測試如何設計用例？
介面測試一般考慮入參形式的變化和介面的業務邏輯。
一般設計介面測試用例採用等價類、邊界值、場景法居多。
介面測試用例設計思路：
（1）介面業務邏輯測試，介面邏輯測試是指根據業務邏輯，輸入參數，輸出值的描述，對正常輸入情況下所得輸出值是否正確的測試，也就是測試對外提供的介面服務是否正常。
（2）模塊介面測試，模塊介面測試是為了保證數據的安全及程序在異常情況下的邏輯正確性而進行的測試模塊，介面測試主要包括以下幾個方面
a.鑒權碼 token 異常（為空、沒有、錯誤、過期）
b.其他參數的異常，必填項的檢查，參數的長度、類型、格式異常。常規的參數有數字，字元串，日期；參數長度，位數、身份證、電話的長度；參數的類型，數字精度，字母，中文，帶空格的參數，特殊字元；日期格式，日期年月日，年月日時分秒，日期格式（包含/-:等）
c.錯誤碼異常覆蓋
11、通用介面用例設計？
（1）通過性驗證：首先肯定要保證這個介面功能是好使的，也就是正常的通過性測試，按照介面文檔上的參數，正常傳入，是否可以返回正確的結果。
（2）參數組合：現在有一個操作商品的介面，有個欄位 type，傳 1 的時候代表修改商品，商品 id、商品名稱、價格有一個是必傳的，type 傳 2 的時候是刪除商品，商品 id 是必傳的，這樣就要測參數組合了，type 傳 1 的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。
（3）介面安全：繞過驗證，比如說購買了一個商品，它的價格是 300 元，那我在提交訂單時候，我把這個商品的價格改成 3 元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的余額還要增加？繞過身份授權，比如說修改商品信息介面，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功。參數是否加密，比如說我登陸的介面，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。密碼安全規則，密碼的復雜程度校驗。
（4）異常驗證：所謂異常驗證，也就是我不按照你介面文檔上的要求輸入參數，來驗證介面對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字元串類型，長度是 10 的，傳 11，總之就是你說怎麼來，我就不怎麼來，其實也就這三種，必傳非必傳、參數類型、入參長度。
12、介面測試報告包含哪些內容？
系統介面概況、測試目的與范圍、測試工具與資源、測試記錄及結果分析（單場景介面、混合場景介面）、測試結論
13、測試指標范圍包含哪些？
（1）被測介面接收請求和返回報文。
（2）被測介面返回狀態、被測介面對應業務邏輯處理、涉及數據沉澱的處理、復雜場景下多個介面串聯交互。
14、做介面測試運用過哪些測試工具？
（1）Postman
（2）JMeter
（3）SoapUI
（4）Python + requests
（5）Java + HttpClient
（6）Java + OkHttp
15、抓包工具用過哪些？
（1）Fiddler
（2）Charles
（3）Wireshark
16、為什麼進行抓包測試？
有些時候公司沒有標準的介面文檔，測試人員只能抓包來獲取介面信息。
抓包可以迅速找到請求，通過抓包可以查看整個請求過程，以及響應過程，可以通過抓包來分辨前台還是後台 bug。
通過抓包，可以查看是否有敏感信息泄露，比如用戶密碼和個人賬號信息等數據。
通過抓包進行測試，攔截請求，修改請求數據，查看對應響應結果，抓包本身就是介面測試的一部分。
17、TCP/IP 參考模型有哪幾層？
應用層、傳輸層、網路層、網路介面層
18、常用協議的埠號？
（1）21/tcp FTP 文件傳輸協議
（2）22/tcp SSH 安全登錄、文件傳送（SCP）和埠重定向
（3）23/tcp Telnet 不安全的文本傳送
（4）25/tcp SMTP Simple Mail Transfer Protocol（E-mail）
（5）69/udp TFTP Trivial File Transfer Protocol（微型文件傳輸協議）
（6）80/tcp HTTP 超文本傳送協議（WWW）
（7）110/tcp POP3 Post Office Protocol（E-mail）
（8）443/tcp HTTPS used for securely transferring web pages
（9）3389/tcp 遠程訪問 5631/tcp
（10）5632/udp pcanywhere 埠號
（11）1433 SqlServer 服務埠號
（12）1521 Oracle 服務埠號
（13）3306 Mysql 服務埠號
（14）8080 Tomcat 默認服務埠號
19、常見的狀態碼有哪些？
（1）1XX 信息提示，用於指定客戶端相應的某些動作。
（2）2XX 成功，用於表示請求成功。
（3）3XX 重定向，用於移動的文件並且常被包含在定位頭信息中制定的新的地址信息。
（4）4XX 客戶端錯誤，用於指出客戶端的錯誤。
（5）5XX 伺服器錯誤，用於指出伺服器的錯誤。
20、你們公司的介面測試流程是怎樣的？
（1）從開發中取得介面文檔，了解介面業務，主要包括介面地址、請求方式、入參、出參、返回格式等信息。
（2）使用 Jmeter 進行介面測試，創建一個線程組，然後建立一個 http 請求默認值，再新建很多 http 請求，一個請求是一個用例，輸入相應介面路徑、訪問方式、參數等，創建斷言和察看結果樹。
（3）最後調用並執行測試用例，編寫測試報告。
（4）在做介面測試的時候遇到過很多問題，都是自己獨立解決的，比如返回值亂碼（修改 Jmeter 的配置文件為 UTF-8）。
21、請詳細闡述介面測試和 UI 測試在測試活動中是如何協同測試的？
介面測試和 UI 測試這兩塊其實是有一部分是重疊的，UI 測試是通過前端寫的界面來調用介面，而介面測試是直接調介面。所以排除前端的處理的邏輯和調用的正確性，在理論上介面測試是可以覆蓋所有的 UI 測試。但實際過程中，如果只是在介面層覆蓋所有的業務流，在 UI 上只測試前端的邏輯，最終的結果可能會是忽視很多原有的功能點，導致了 UI 測試的不充分。所以存在多人分工且時間充分的時候可以嘗試介面去做業務流的全覆蓋，否則不要輕易嘗試。
22、介面測試注意事項？
（1）改變請求參數，看響應結果是否和介面文檔一致。
（2）查看參數是否有敏感信息（比如個人賬戶信息，資金信息）。
（3）查看是否對關鍵參數進行加密處理（密碼信息）。
（4）所有列表頁介面必須考慮排序值。
（5）介面返回的圖片地址能否打開，圖片尺寸是否符合需求。
（6）介面有翻頁時，頁碼與頁數的異常值測試。
（7）當輸出參數有聯動性時，需要校驗返回兩參數的實際結果是否都符合需求每個介面入參的默認值、異常類型、非空校驗。
（8）入參支持多個值時，要考慮傳的值的個數多的情況下，介面會不會報錯。
23、介面測試執行中對比資料庫嗎？
肯定要對比，因為介面返回值的數據來源於資料庫，介面對數據的操作還要進行深層次的資料庫檢查。
24、請簡述一下 cookie、session 以及 token 的區別？
cookie 數據存放在客戶的瀏覽器上、session 數據放在伺服器上、token 是介面測試時鑒權碼，一般情況下登陸後才可以獲取到 token，然後在每次請求介面時需要帶上 token 參數。
cookie 不安全，別人可以分析存在本地的 cookie 並進行 cookie 欺騙，考慮到安全應當使用 session 可以將登錄信息等重要信息存放為 session，其他信息可以保存在 cookie。
25、談談你對 HTTP 協議的了解？
超文本傳輸協議，埠為 80，是由請求和響應兩部分組成的。
請求是由請求頭，請求行，請求正文組成；響應是由響應頭、響應行、響應正文組成。
面向安全的話使用 https。
26、你對 http 請求跟 webservice 請求的了解？
（1）http api 介面：是走 http 協議，通過路徑來區分調用的方法，請求報文都是 key-value 形式的，返回報文一般都是 json 串，有 get 和 post 等方法，這也是最常用的兩種請求方式。可以使用的工具有 postman、RESTClient、jmeter、loadrunner 等。
（2）webservice 介面：是走 soap 協議通過 http 傳輸，請求報文和返回報文都是 xml 格式的，都是通過工具才能進行調用與測試。可以使用的工具有 SoapUI、jmeter、loadrunner 等。
27、在介面測試中關聯是什麼含義？如何使用 Postman 設置關聯？
關聯就是把上一個介面返回值的部分截取出來，作為下一個介面的參數，能讓介面串聯運行。
在 Postman 中設置關聯的步驟如下：
（1）通過正則表達式提取的方式或 json 取值的方式把下一個介面需要的信息從上一個介面截取出來。
（2）使用設置全局變數的代碼把取出來的值保存到全局變數里。
（3）在下一個介面中，使用(全局變數)代替要替換的靜態值。
28、介面自動化測試框架一般分為幾層？
自動化測試框架一般分為 5 層（配置層，腳本層，數據層，測試報告層，驅動層）
介面項目工程規劃大致可分為幾類，首先是測試結果類，比如說叫 test_rusult，裡面存放一些比如日誌文件，測試報告。然後是測試用例 testcase，裡面分模塊存放測試用例。接下來是公共方法類，比如說叫 public，或者是 tools，裡面存放一些，讀取 excel 數據的方法，發送 http 請求的方法，收集 log 日誌的方法，發送郵件，操作資料庫等方法。還有就是配置文件類，比如說叫 config，裡面存放一些指定運行部分用例的配置文件，連接資料庫的配置文件。最後是寫一個 run 方法，運行所有的用例。
29、測試框架里如何做到數據和代碼分離？
第一種：寫在 excel 表格里，像這種主要是讀取 excel 數據有點麻煩，常用的用來讀取 excel 的第三方庫有 openpyxl，xlrd 等。當然讀取 excel 數據最好用的還是用來做數據分析的 pandas 模塊，不用寫那麼多 for 循環。
第二種：數據存放到 yaml 文件里，一個模塊或者是一個功能寫一個 yaml 文件，最後寫個讀取 yaml 文件的公共方法就行了。yaml 格式的文件比較簡單。
第三種：存放在資料庫裡面。
第四種：數據存放在 json 文件里。
㈥ 實現MySQL資料庫的備份與還原的幾種方法
MyISAM 表是保存成文件的形式，因此相對比較容易備份，上面提到的幾種方法都可以使用。Innodb 所有的表都保存在同一個數據文件 ibdata1 中（也可能是多個文件，或者是獨立的表空間文件），相對來說比較不好備份，免費的方案可以是拷貝數據文件、備份 binlog，或者用 mysqlmp。1. 使用直接拷貝資料庫備份 典型的如cp、tar或cpio實用程序當你使用直接備份方法時，必須保證表不在被使用。如果伺服器在你正在拷貝一個表時改變它，拷貝就失去意義。保證你的拷貝完整性的最好方法是關閉伺服器，拷貝文件，然後重啟伺服器。 如果你不想關閉伺服器，要在執行表檢查的同時鎖定伺服器。如果伺服器在運行，相同的制約也適用於拷貝文件，應該使用相同的鎖定協議讓伺服器「安靜下來」。當你完成了MySQL資料庫備份時，需要重啟伺服器（如果關閉了它）或釋放加在表上的鎖定（如果你讓伺服器運行）。 要用直接拷貝文件把一個資料庫從一台機器拷貝到另一台機器上，只是將文件拷貝到另一台伺服器主機的適當數據目錄下即可。要確保文件是MyIASM格式或兩台機器有相同的硬體結構，否則你的資料庫在另一台主機上有奇怪的內容。你也應該保證在另一台機器上的伺服器在你正在安裝資料庫表時不訪問它們。2. 使用mysqlmp資料庫備份mysqlmp 是採用SQL級別的備份機制，它將數據表導成 SQL 腳本文件，在不同的 MySQL 版本之間升級時相對比較合適，這也是最常用的備份方法。mysqlmp程序備份資料庫較慢，但它生成的文本文件便於移植。mysqlmp 的一些主要參數：1）--compatible=name它告訴 mysqlmp，導出的數據將和哪種資料庫或哪個舊版本的 MySQL 伺服器相兼容。值可以為 ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options 等，要使用幾個值，用逗號將它們隔開。當然了，它並不保證能完全兼容，而是盡量兼容。2）--complete-insert，-c導出的數據採用包含欄位名的完整 INSERT 方式，也就是把所有的值都寫在一行。這么做能提高插入效率，但是可能會受到 max_allowed_packet 參數的影響而導致插入失敗。因此，需要謹慎使用該參數，至少我不推薦。3）--default-character-set=charset指定導出數據時採用何種字元集，如果數據表不是採用默認的 latin1 字元集的話，那麼導出時必須指定該選項，否則再次導入數據後將產生亂碼問題。4）--disable-keys告訴mysqlmp 在 INSERT 語句的開頭和結尾增加 ; 和 ; 語句，這能大大提高插入語句的速度，因為它是在插入完所有數據後才重建索引的。該選項只適合 MyISAM 表。5）--extended-insert = true|false默認情況下，mysqlmp 開啟 --complete-insert 模式，因此不想用它的的話，就使用本選項，設定它的值為 false 即可。6）--hex-blob使用十六進制格式導出二進制字元串欄位。如果有二進制數據就必須使用本選項。影響到的欄位類型有 BINARY、VARBINARY、BLOB。7）--lock-all-tables，-x在開始導出之前，提交請求鎖定所有資料庫中的所有表，以保證數據的一致性。這是一個全局讀鎖，並且自動關閉 --single-transaction 和 --lock-tables 選項。8）--lock-tables它和--lock-all-tables 類似，不過是鎖定當前導出的數據表，而不是一下子鎖定全部庫下的表。本選項只適用於 MyISAM 表，如果是 Innodb 表可以用 --single-transaction 選項。9）--no-create-info，-t只導出數據，而不添加 CREATE TABLE 語句。10）--no-data，-d不導出任何數據，只導出資料庫表結構。11）--opt這只是一個快捷選項，等同於同時添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 選項。本選項能讓 mysqlmp 很快的導出數據，並且導出的數據能很快導回。該選項默認開啟，但可以用 --skip-opt 禁用。注意，如果運行 mysqlmp 沒有指定 --quick 或 --opt 選項，則會將整個結果集放在內存中。如果導出大資料庫的話可能會出現問題。12）--quick，-q該選項在導出大表時很有用，它強制 mysqlmp 從伺服器查詢取得記錄直接輸出而不是取得所有記錄後將它們緩存到內存中。13）--routines，-R導出存儲過程以及自定義函數。14）--single-transaction該選項在導出數據之前提交一個 BEGIN SQL語句，BEGIN 不會阻塞任何應用程序且能保證導出時資料庫的一致性狀態。它只適用於事務表，例如 InnoDB 和 BDB。 本選項和 --lock-tables 選項是互斥的，因為 LOCK TABLES 會使任何掛起的事務隱含提交。 要想導出大表的話，應結合使用 --quick 選項。--triggers同時導出觸發器。該選項默認啟用，用 --skip-triggers 禁用它。備份：使用mysqlmp備份資料庫其實就是把資料庫轉儲成一系列CREATE TABLE和INSERT語句，通過這些語句我們就可重新生成資料庫。使用mysqlmp的方法如下：% mysqlmp --opt testdb | gzip > /data/backup/testdb.bak#--opt選項會對轉儲過程進行優化，生成的備份文件會小一點，後的管道操作會進行數據壓縮% mysqlmp --opt testdb mytable1,mytable2 | gzip > /data/backup/testdb_mytable.bak#可在資料庫後接數據表名，只導出指定的數據表，多個數據表可用逗號分隔--opt選項還可激活--add-drop-table選項，它將會在備份文件的每條CREATE TABLE前加上一條DROP TABLE IF EXISTS語句。這可方便進行數據表的更新，而不會發生「數據表已存在」的錯誤。用mysqlmp命令還可直接把資料庫轉移到另外一台伺服器上，不用生成備份文件。重復執行可定期更新遠程資料庫。% mysqladmin -h remote_host create testdb% mysqlmp --opt testdb | mysql -h remote_host testdb另外還可通過ssh遠程調用伺服器上的程序，如：% ssh remote_host mysqladmin create testdb% mysqlmp --opt testdb | ssh remote_host mysql testdb 通過直接拷貝系統文件的方式備份資料庫，在備份時，要確保沒有人對資料庫進行修改操作。要做到這點，最好關閉伺服器。如果不能關閉的，要以只讀方試鎖定有關數據表。下面是一些示例：% cp -r db /backup/db #備份db資料庫到/backup/db目錄% cp table_name.* /backup/db #只備份table_name數據表% scp -r db remotehot:/usr/local/mysql/data #用scp把資料庫直接拷貝到遠程伺服器，在把資料庫直接拷貝到遠程主機時，應注意兩台機器必須有同樣的硬體結構，或者將拷貝的數據表全部是可移植數據表類型。或者/usr/local/mysql/bin/mysqlmp -uroot -proot \--default-character-set=utf8 --opt --extended-insert=false \--triggers -R --hex-blob -x testdb > testdb.sql使用以下 SQL 來備份 Innodb 表：/usr/local/mysql/bin/mysqlmp -uroot -proot \--default-character-set=utf8 --opt --extended-insert=false \--triggers -R --hex-blob --single-transaction testdb > testdb.sql另外，如果想要實現在線備份，還可以使用 --master-data 參數來實現，如下：/usr/local/mysql/bin/mysqlmp -uroot -proot \--default-character-set=utf8 --opt --master-data=1 \--single-transaction --flush-logs testdb > testdb.sql它只是在一開始的瞬間請求鎖表，然後就刷新binlog了，而後在導出的文件中加入CHANGE MASTER 語句來指定當前備份的binlog位置，如果要把這個文件恢復到slave里去，就可以採用這種方法來做。 還原：用mysqlmp 備份出來的文件是一個可以直接倒入的 SQL 腳本，有兩種方法可以將數據導入。直接用 mysql 客戶端例如：/usr/local/mysql/bin/mysql -uroot -proot testdb < testdb.sql用SOURCE 語法其實這不是標準的 SQL 語法，而是 mysql 客戶端提供的功能，例如：SOURCE /tmp/testdb.sql;這里需要指定文件的絕對路徑，並且必須是 mysqld 運行用戶(例如 nobody)有許可權讀取的文件。 3. 使用mysqlhot資料庫備份 使用mysqlhot工具，它是一個Perl DBI腳本，可在不關閉伺服器的情況下備份資料庫，mysqlhot 是一個 PERL 程序，最初由Tim Bunce編寫。它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 來快速備份資料庫。它是備份資料庫或單個表的最快的途徑，但它只能運行在資料庫文件（包括數據表定義文件、數據文件、索引文件）所在的機器上。mysqlhot 只能用於備份 MyISAM，並且只能運行在 類Unix 和 NetWare 系統上。它主要的優點是：它直接拷貝文件，所以它比mysqlmp快。可自動完成數據鎖定工作，備份時不用關閉伺服器。能刷新日誌，使備份文件和日誌文件的檢查點能保持同步。備份：mysqlhot 支持一次性拷貝多個資料庫，同時還支持正則表達。以下是幾個例子：/usr/local/mysql/bin/mysqlhot -h=localhost -u=root -p=root \testdb /tmp (把資料庫目錄 testdb 拷貝到 /tmp 下)/usr/local/mysql/bin/mysqlhot -h=localhost -u=root -p=root \testdb_1 testdb_2 testdb_n /tmp/usr/local/mysql/bin/mysqlhot -h=localhost -u=root -p=root \testdb./regex/ /tmp 還原：mysqlhot 備份出來的是整個資料庫目錄，使用時可以直接拷貝到 mysqld 指定的 datadir (在這里是 /usr/local/mysql/data/)目錄下即可，同時要注意許可權的問題，如下例：cp -rf testdb /usr/local/mysql/data/chown -R nobody:nobody /usr/local/mysql/data/ (將 testdb 目錄的屬主改成 mysqld 運行用戶) 4. 使用SQL語句資料庫備份 BACKUP TABLE 語法其實和 mysqlhot 的工作原理差不多，都是鎖表，然後拷貝數據文件。它能實現在線備份，但是效果不理想，因此不推薦使用。它只拷貝表結構文件和數據文件，不同時拷貝索引文件，因此恢復時比較慢。備份：BACK TABLE tbl_test TO '/tmp/testdb/'; #把tbl_test資料庫備份到/tmp/testdb/目錄里，會自動創建一個testdb目錄 為了執行該語句，你必須擁有那些表的FILE許可權和SELECT許可權，備份目錄還必須是伺服器可寫的。該語句執行時，會先把內存中的數據寫入磁碟，再把各個數據表的.frm(表結構定義文件)、.MYD(數據)文件從數據目錄拷貝到備份目錄。它不拷貝.MYI(索引)文件，因為它能用另外兩個文件重建。BACKUP TABLE語句備份時，依次鎖定數據表，當同時備份多個數據表時，數據表可能會被修改，所以備份0完成時，備份文件中的數據和現時數據表中的數據可能會有差異，為了消除該差異，我們可用只讀方式鎖定數據表，在備份完成後再解鎖。如：mysql> LOCK TABLES tb1 READ,tb2 READ;mysql> BACKUP TABLE tb1,tb2 TO 'backup/db';mysql> UNLOCK TABLES;使用BACKUP TABLE語句備份的數據表可用RESTORE TABLE重新載入到伺服器。注意，必須要有 FILE 許可權才能執行本SQL，並且目錄 /tmp/testdb/ 必須能被 mysqld 用戶可寫，導出的文件不能覆蓋已經存在的文件，以避免安全問題。SELECT INTO OUTFILE 則是把數據導出來成為普通的文本文件，可以自定義欄位間隔的方式，方便處理這些數據。 例子：SELECT * INTO OUTFILE '/tmp/testdb/tbl_test.txt' FROM tbl_test;注意，必須要有 FILE 許可權才能執行本SQL，並且文件 /tmp/testdb/tbl_test.txt 必須能被 mysqld 用戶可寫，導出的文件不能覆蓋已經存在的文件，以避免安全問題。還原：用BACKUP TABLE 方法備份出來的文件，可以運行 RESTORE TABLE 語句來恢復數據表。例子：RESTORE TABLE FROM '/tmp/testdb/';許可權要求類似上面所述。用SELECT INTO OUTFILE 方法備份出來的文件，可以運行 LOAD DATA INFILE 語句來恢復數據表。例子：LOAD DATA INFILE '/tmp/testdb/tbl_name.txt' INTO TABLE tbl_name;許可權要求類似上面所述。倒入數據之前，數據表要已經存在才行。
㈦ 怎麼恢復mysql資料庫怎麼恢復數據
簡單情況下：進入原來mysql安裝路徑下的data文件夾下，找到相應的庫和ibdata1，進行，就可回復原來的數據。
復雜情況下：
從另一台機上把MySQL資料庫的mysql文件夾拷貝到本地機上，目的是恢復本地機對數據的訪問和操作。經過如下幾種情況的操作。
1.
在本地重裝MySQL（安裝目錄D:\Program
Files\MySQL\MySQL
Server
5.0），直接把mysql文件夾拷貝至D:\Program
Files\MySQL\MySQL
Server
5.0\。結果，失敗：資料庫連接錯誤。
2.
卸載後重裝MySQL，將D:\Program
Files\MySQL\MySQL
Server
5.0\下的數據備份，只把mysql\data文件夾全部內容拷貝到D:\Program
Files\MySQL\MySQL
Server
5.0\data下。結果，失敗：資料庫連接錯誤。將備份的數據還完覆蓋。結果，失敗，還是連接不上資料庫。
3.
卸載後重裝MySQL，將mysql\data文件夾里的cf1,last文件夾（這兩個是原來MySQL里的資料庫）拷貝進D:\Program
Files\MySQL\MySQL
Server
5.0\data。連接成功，在Navicat
for
MySQL里看到資料庫cf1和last，但是不能訪問，因為數據全為零。明白了原來data里以資料庫命名的文件存儲的是資料庫的表結構，不是元數據。下一步，把data文件夾里的ibdata1文件（3.4G大，明顯存儲了元數據）拷貝到D:\Program
Files\MySQL\MySQL
Server
5.0\data里，代替原來的ibdata1文件。重啟電腦，打開Navicat
for
MySQL，連接成功，數據可以訪問操作。
至此，操作終於成功。其實當初在那台機上把數據導出來，而不是現在直接把文件夾mysql復制過來會更容易恢復。但那台機已經重裝了系統，也就是說MySQL失效了。
㈧ XtraBackup 備份指定庫
Xtrabackup 是由 percona 開源的免費資料庫熱備份軟體，它能對 InnoDB 和 XtraDB 存儲引擎的資料庫非阻塞地備份。
為了方便建立從庫，Xtrabackup 在備份完成後會將 binlog position 與 GTID 的相關信息保存於 xtrabackup_binlog_info 文件中。但是當你使用 Xtrabackup 生成的備份建立一個從庫時，會發現恢復後的實例執行 show master status，顯示的 Executed_Gtid_Set 與 xtrabackup_binlog_info 文件中記錄的信息並不一致，而且使用 Xtrabackup 2.4 與 8.0（對 MySQL 8.0 進行備份）生成的備份在恢復後，信息不一致的表現又不相同。本篇文章主要針對該現象進行簡單的分析。
一、Xtrabackup 2.4.18 for MySQL 5.7.26
現象
1. 使用 Xtrabackup 工具備份後，xtrabackup_binlog_info 文件記錄的信息如下：# cat xtrabackup_binlog_infomysql-bin.000003 86412752 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-595859
2. 將該備份恢復至一個新實例並啟動該實例，執行 show master status; 查看信息：mysql> show master statusG*************************** 1. row *************************** File: mysql-bin.000001 Position: 154 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02000aba3fa6:1-3266611 row in set (0.00 sec)
此時會發現使用備份恢復的實例顯示已執行過的 GTID 是 1-326661，而備份文件顯示的是 1-595859，這是否表示兩者相差的 GTID:326662-595859 代表的事務丟失了？通過對原實例（進行備份的實例）的 binlog 進行解析，來查詢 GTID:326662-595859 這部分事務所生成的數據在新實例（通過備份恢復的實例）上是否存在。可以發現 GTID:326662-595859 這部分事務的數據都存在於新實例上，也就是說數據與 xtrabackup_binlog_info 文件記錄的是一致的，只不過與 show master status 命令獲取的信息的不一致。
原因分析
首先我們要清楚 Xtrabackup 2.4 的備份流程，大致如下：
1. start backup
2. ibdata1 / .ibd file
3. Excuted ftwrl
4. backup non-InnoDB tables and files
5. Writing xtrabackup_binlog_info
6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7. Executed UNLOCK TABLES
8. Copying ib_buffer_pool
9. completed OK!
結合備份時的 general log 可知，Xtrabackup 在執行 ftwrl 並備份完所有非 InnoDB 表格的文件後通過 show master status 獲取了 binlog position 和 GTID 的信息，將其記錄到 xtrabackup_binlog_info 文件中。
那麼 show master status 獲取的是哪些信息？
該命令提供本實例的 binlog 文件的狀態信息，顯示正在寫入的 binlog 文件，以及當前的binlog position，並且 MySQL 5.7 在 MySQL 庫下引入了 gtid_executed 表，該表會記錄當前執行過的 GTID。
那麼目前看來問題可能就出在 gtid_executed 表格上，通過測試和官方文檔提供的信息可知，該表格雖然是 InnoDB 表，但是其中的數據並非是實時更新的，且該表格記錄信息的方式存在以下兩個情況：1. 如果禁用了 log_bin，實例不會在該表格記錄任何信息；若從庫的 log_slave_updates 為 OFF，那麼從庫會在應用 relay-log 中的每個事務時執行一次 insert mysql.gtid_executed 的操作。2. 如果啟用了 log_bin，則該表格記錄的是在 binlog 發生切換（rotate）的時候直到上一個 binlog 文件執行過的全部 GTID，而此時 show master status 獲取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系統變數 gtid_exected 提供；如果伺服器意外停止，則當前 binlog 文件中的 Gtid 集合不會保存在 mysql.gtid_executed 表中，在實例恢復期間，這些 Gtid 從 binlog 文件中讀取並添加到表中。
小結
所以當備份恢復時，實際 show master status 可能會出現以下情況：1. 當 log_bin 禁用或者 log_slave_updates 為 OFF 時，備份恢復後的實例 show master status 顯示為空。2. 當開啟了 log_bin，但是該實例並未發生過 binlog 的切換時，備份恢復後的實例 show master status 顯示也為空。3. 當開啟了 log_bin，其該實例的 binlog 發生過切換時，備份恢復後的實例 show master status 顯示的信息會比 xtrabackup_binlog_info 文件中記錄的 GTID 缺失一部分，這一部分就是 mysql.gtid_executed 表格未記錄的部分。
二、Xtrabackup 8.0.8 for MySQL 8.0.18現象1. 使用 Xtrabackup 工具備份後，xtrabackup_binlog_info 文件記錄的信息如下：# # cat xtrabackup_binlog_infobinlog.000033 1459 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-621683
2. 查看備份實例相對應的 binlog 解析後的內容：
# mysqlbinlog -vv binlog.000033 | less
定位至 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683
# at 508
#200213 13:46:47 server id 663728 end_log_pos 583 GTID last_committed=0 sequence_number=2 rbr_only=yes original_committed_timestamp=1581572807720907 immediate_commit_timestamp=15815728
07720907 transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)
# immediate_commit_timestamp=1581572807720907 (2020-02-13 13:46:47.720907 CST)
/*!80001 SET @@session.original_commit_timestamp=1581572807720907*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621683'/*!*/;
# at 583
#200213 13:46:47 server id 663728 end_log_pos 659 Query thread_id=214 exec_time=0 error_code=0
SET TIMESTAMP=1581572807/*!*/;
BEGIN
/*!*/;
# at 659
#200213 13:46:47 server id 663728 end_log_pos 708 Rows_query
# insert into t1 values(null,2)
# at 708
#200213 13:46:47 server id 663728 end_log_pos 758 Table_map: `mysqlslap`.`t1` mapped to number 314
# at 758
#200213 13:46:47 server id 663728 end_log_pos 798 Write_rows: table id 314 flags: STMT_END_F
BINLOG '
x+==
x+=
x+/wCKAAEAAgAAAA==
'/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65674 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 798
#200213 13:46:47 server id 663728 end_log_pos 825 Xid = 2436045
COMMIT/*!*/;
- 可以發現該文件提供的 binlog position 與 GTID 並不對應。而 binlog.000033:1459 對應的 GTID 是 70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685 提交後的下一個位置：
# at 1142
#200213 13:46:47 server id 663728 end_log_pos 1217 GTID last_committed=2 sequence_number=4 rbr_only=yes original_committed_timestamp=1581572807724646 immediate_commit_timestamp=15815728
07724646 transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)
# immediate_commit_timestamp=1581572807724646 (2020-02-13 13:46:47.724646 CST)
/*!80001 SET @@session.original_commit_timestamp=1581572807724646*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '70ec927f-4c6d-11ea-b88c-02000aba3fb1:621685'/*!*/;
# at 1217
#200213 13:46:47 server id 663728 end_log_pos 1293 Query thread_id=215 exec_time=0 error_code=0
SET TIMESTAMP=1581572807/*!*/;
BEGIN
/*!*/;
# at 1293
#200213 13:46:47 server id 663728 end_log_pos 1342 Rows_query
# insert into t1 values(null,2)
# at 1342
#200213 13:46:47 server id 663728 end_log_pos 1392 Table_map: `mysqlslap`.`t1` mapped to number 314
# at 1392
#200213 13:46:47 server id 663728 end_log_pos 1432 Write_rows: table id 314 flags: STMT_END_F
BINLOG '
x+==
x+=
x+/wCMAAEAAgAAAA==
'/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65676 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 1432
#200213 13:46:47 server id 663728 end_log_pos 1459 Xid = 2436047
COMMIT/*!*/;
# at 1459
- 3. 再看將備份恢復到一個新實例並啟動後，執行 show master status 顯示的信息：mysql> show master statusG*************************** 1. row *************************** File: binlog.000034 Position: 191 Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02000aba3fb1:1-6216851 row in set (0.00 sec)
- 可以發現與 Xtrabackup 2.4 不同的是，該備份的 xtrabackup_binlog_info 文件記錄的信息並不準確，而備份恢復後顯示的信息卻是准確的。
- 首先我們來看一下 Xtrabackup 8.0 針對 MySQL 8.0 備份的大致過程：1. start backup2. .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. ib_buffer_pool11. completed OK!由以上步驟可知，Xtrabackup 8.0 對 MySQL 8.0 的備份與 Xtrabackup 2.4 略有不同，根據 percona 官方文檔的信息，當 MySQL 8.0 中僅存在 InnoDB 引擎的表格時，不再執行ftwrl（當存在非 InnoDB 的表格或者使用 --slave-info 選項時會執行），而是根據上述步驟的第 5 步，Xtrabackup 8.0 會通過SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
- 來獲取 LSN 、binlog position and Gtid。1.performance_schema.log_status 是 MySQL 8.0 提供給在線備份工具獲取復制日誌文件信息的表格。查詢 log_status 表時，伺服器將阻止日誌的記錄和相關的更改來獲取足夠的時間以填充該表，然後釋放資源。Log_status 表通知在線備份工具應記錄主庫的 binlog 的哪個位點和 gtid_executed 的值，還有每個復制通道的 relay log。它還為各個存儲引擎提供了相關信息，例如 InnoDB 存儲引擎使用的最後一個日誌序列號（LSN）和最後一個檢查點的 LSN。2. 經過測試發現，當無數據寫入時， performance_schema.log_status 提供的 binlog position 與 GTID 是一致的，但是當有大量數據持續寫入時，該表格提供的 binlog position 與 GTID 信息將不再一致，如下圖：
原因