A. 大數據核心技術有哪些
大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、Nosql資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。首先給出一個通用化的大數據處理框架，主要分為下面幾個方面：數據採集與預處理、數據存儲、數據清洗、數據查詢分析和數據可視化。
一、數據採集與預處理
對於各種來源的數據，包括移動互聯網數據、社交網路的數據等，這些結構化和非結構化的海量數據是零散的，也就是所謂的數據孤島，此時的這些數據並沒有什麼意義，數據採集就是將這些數據寫入數據倉庫中，把零散的數據整合在一起，對這些數據綜合起來進行分析。數據採集包括文件日誌的採集、資料庫日誌的採集、關系型資料庫的接入和應用程序的接入等。在數據量比較小的時候，可以寫個定時的腳本將日誌寫入存儲系統，但隨著數據量的增長，這些方法無法提供數據安全保障，並且運維困難，需要更強壯的解決方案。
Flume NG作為實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據，同時，對數據進行簡單處理，並寫到各種數據接收方(比如文本，HDFS，Hbase等)。Flume NG採用的是三層架構：Agent層，Collector層和Store層，每一層均可水平拓展。其中Agent包含Source，Channel和 Sink，source用來消費（收集）數據源到channel組件中，channel作為中間臨時存儲，保存所有source的組件信息，sink從channel中讀取數據，讀取成功之後會刪除channel中的信息。
NDC，Netease Data Canal，直譯為網易數據運河系統，是網易針對結構化資料庫的數據實時遷移、同步和訂閱的平台化解決方案。它整合了網易過去在數據傳輸領域的各種工具和經驗，將單機資料庫、分布式資料庫、OLAP系統以及下游應用通過數據鏈路串在一起。除了保障高效的數據傳輸外，NDC的設計遵循了單元化和平台化的設計哲學。
Logstash是開源的伺服器端數據處理管道，能夠同時從多個來源採集數據、轉換數據，然後將數據發送到您最喜歡的 「存儲庫」 中。一般常用的存儲庫是Elasticsearch。Logstash 支持各種輸入選擇，可以在同一時間從眾多常用的數據來源捕捉事件，能夠以連續的流式傳輸方式，輕松地從您的日誌、指標、Web 應用、數據存儲以及各種 AWS 服務採集數據。
Sqoop，用來將關系型資料庫和Hadoop中的數據進行相互轉移的工具，可以將一個關系型資料庫(例如Mysql、Oracle)中的數據導入到Hadoop(例如HDFS、Hive、Hbase)中，也可以將Hadoop(例如HDFS、Hive、Hbase)中的數據導入到關系型資料庫(例如Mysql、Oracle)中。Sqoop 啟用了一個 MapRece 作業（極其容錯的分布式並行計算）來執行任務。Sqoop 的另一大優勢是其傳輸大量結構化或半結構化數據的過程是完全自動化的。
流式計算是行業研究的一個熱點，流式計算對多個高吞吐量的數據源進行實時的清洗、聚合和分析，可以對存在於社交網站、新聞等的數據信息流進行快速的處理並反饋，目前大數據流分析工具有很多，比如開源的strom，spark streaming等。
Strom集群結構是有一個主節點（nimbus）和多個工作節點（supervisor）組成的主從結構，主節點通過配置靜態指定或者在運行時動態選舉，nimbus與supervisor都是Storm提供的後台守護進程，之間的通信是結合Zookeeper的狀態變更通知和監控通知來處理。nimbus進程的主要職責是管理、協調和監控集群上運行的topology（包括topology的發布、任務指派、事件處理時重新指派任務等）。supervisor進程等待nimbus分配任務後生成並監控worker（jvm進程）執行任務。supervisor與worker運行在不同的jvm上，如果由supervisor啟動的某個worker因為錯誤異常退出（或被kill掉），supervisor會嘗試重新生成新的worker進程。
當使用上游模塊的數據進行計算、統計、分析時，就可以使用消息系統，尤其是分布式消息系統。Kafka使用Scala進行編寫，是一種分布式的、基於發布/訂閱的消息系統。Kafka的設計理念之一就是同時提供離線處理和實時處理,以及將數據實時備份到另一個數據中心，Kafka可以有許多的生產者和消費者分享多個主題，將消息以topic為單位進行歸納；Kafka發布消息的程序稱為procer，也叫生產者，預訂topics並消費消息的程序稱為consumer，也叫消費者；當Kafka以集群的方式運行時，可以由一個服務或者多個服務組成，每個服務叫做一個broker，運行過程中procer通過網路將消息發送到Kafka集群，集群向消費者提供消息。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Procer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息。Kafka可以和Flume一起工作，如果需要將流式數據從Kafka轉移到hadoop，可以使用Flume代理agent，將Kafka當做一個來源source，這樣可以從Kafka讀取數據到Hadoop。
Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。它的作用主要有配置管理、名字服務、分布式鎖和集群管理。配置管理指的是在一個地方修改了配置，那麼對這個地方的配置感興趣的所有的都可以獲得變更，省去了手動拷貝配置的繁瑣，還很好的保證了數據的可靠和一致性，同時它可以通過名字來獲取資源或者服務的地址等信息，可以監控集群中機器的變化，實現了類似於心跳機制的功能。
二、數據存儲
Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。
HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。HBase是一種Key/Value系統，部署在hdfs上，克服了hdfs在隨機讀寫這個方面的缺點，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。
Phoenix，相當於一個Java中間件，幫助開發工程師能夠像使用JDBC訪問關系型資料庫一樣訪問NoSQL資料庫HBase。
Yarn是一種Hadoop資源管理器，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。Yarn由下面的幾大組件構成：一個全局的資源管理器ResourceManager、ResourceManager的每個節點代理NodeManager、表示每個應用的Application以及每一個ApplicationMaster擁有多個Container在NodeManager上運行。
Mesos是一款開源的集群管理軟體，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應用架構。
Redis是一種速度非常快的非關系資料庫，可以存儲鍵與5種不同類型的值之間的映射，可以將存儲在內存的鍵值對數據持久化到硬碟中，使用復制特性來擴展性能，還可以使用客戶端分片來擴展寫性能。
Atlas是一個位於應用程序與MySQL之間的中間件。在後端DB看來，Atlas相當於連接它的客戶端，在前端應用看來，Atlas相當於一個DB。Atlas作為服務端與應用程序通訊，它實現了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。Atlas啟動後會創建多個線程，其中一個為主線程，其餘為工作線程。主線程負責監聽所有的客戶端連接請求，工作線程只監聽主線程的命令請求。
Ku是圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，它運行在普通的伺服器上、可分布式規模化部署、並且滿足工業界的高可用要求。其設計理念為fast analytics on fast data。作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Ku不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。Ku的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等。
在數據存儲過程中，涉及到的數據表都是成千上百列，包含各種復雜的Query，推薦使用列式存儲方法，比如parquent,ORC等對數據進行壓縮。Parquet 可以支持靈活的壓縮選項，顯著減少磁碟上的存儲。
三、數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map（映射）」和」Rece（歸約）」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。
隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
Oozie是用於Hadoop平台的一種工作流調度引擎，提供了RESTful API介面來接受用戶的提交請求(提交工作流作業)，當提交了workflow後，由工作流引擎負責workflow的執行以及狀態的轉換。用戶在HDFS上部署好作業(MR作業)，然後向Oozie提交Workflow，Oozie以非同步方式將作業(MR作業)提交給Hadoop。這也是為什麼當調用Oozie 的RESTful介面提交作業之後能立即返回一個JobId的原因，用戶程序不必等待作業執行完成（因為有些大作業可能會執行很久(幾個小時甚至幾天)）。Oozie在後台以非同步方式，再將workflow對應的Action提交給hadoop執行。
Azkaban也是一種工作流的控制引擎，可以用來解決有多個hadoop或者spark等離線計算任務之間的依賴關系問題。azkaban主要是由三部分構成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban將大多數的狀態信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、認證、調度以及對工作流執行過程中的監控等；Azkaban Executor Server用來調度工作流和任務，記錄工作流或者任務的日誌。
流計算任務的處理平台Sloth，是網易首個自研流計算平台，旨在解決公司內各產品日益增長的流計算需求。作為一個計算服務平台，其特點是易用、實時、可靠，為用戶節省技術方面（開發、運維）的投入，幫助用戶專注於解決產品本身的流計算需求。
四、數據查詢分析
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece 、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。
Hive是為大數據批量處理而生的，Hive的出現解決了傳統的關系型資料庫(MySql、Oracle)在大數據處理上的瓶頸 。Hive 將執行計劃分成map->shuffle->rece->map->shuffle->rece…的模型。如果一個Query會被編譯成多輪MapRece，則會有更多的寫中間結果。由於MapRece執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。在Hive的運行過程中，用戶只需要創建表，導入數據，編寫SQL分析語句即可。剩下的過程由Hive框架自動的完成。
Impala是對Hive的一個補充，可以實現高效的SQL查詢。使用Impala來實現SQL on Hadoop，用來進行大數據實時查詢分析。通過熟悉的傳統關系型資料庫的SQL風格來操作大數據，同時數據也是可以存儲到HDFS和HBase中的。Impala沒有再使用緩慢的Hive+MapRece批處理，而是通過使用與商用並行關系資料庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。Impala將整個查詢分成一執行計劃樹，而不是一連串的MapRece任務，相比Hive沒了MapRece啟動時間。
Hive 適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢，Impala給數據人員提供了快速實驗，驗證想法的大數據分析工具，可以先使用Hive進行數據轉換處理，之後使用Impala在Hive處理好後的數據集上進行快速的數據分析。總的來說：Impala把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的map->rece模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。但是Impala不支持UDF，能處理的問題有一定的限制。
Spark擁有Hadoop MapRece所具有的特點，它將Job中間輸出結果保存在內存中，從而不需要讀取HDFS。Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。
Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬蟲。
Solr用Java編寫、運行在Servlet容器（如Apache Tomcat或Jetty）的一個獨立的企業級搜索應用的全文搜索伺服器。它對外提供類似於Web-service的API介面，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引；也可以通過Http Get操作提出查找請求，並得到XML格式的返回結果。
Elasticsearch是一個開源的全文搜索引擎，基於Lucene的搜索伺服器，可以快速的儲存、搜索和分析海量的數據。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
還涉及到一些機器學習語言，比如，Mahout主要目標是創建一些可伸縮的機器學習演算法，供開發人員在Apache的許可下免費使用；深度學習框架Caffe以及使用數據流圖進行數值計算的開源軟體庫TensorFlow等，常用的機器學習演算法比如，貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。
五、數據可視化
對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。主流的BI平台比如，國外的敏捷BI Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數（可點擊這里免費試用）等。
在上面的每一個階段，保障數據的安全是不可忽視的問題。
基於網路身份認證的協議Kerberos，用來在非安全網路中，對個人通信以安全的手段進行身份認證，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。
控制許可權的ranger是一個Hadoop集群許可權框架，提供操作、監控、管理復雜的數據許可權，它提供一個集中的管理機制，管理基於yarn的Hadoop生態圈的所有數據許可權。可以對Hadoop生態的組件如Hive，Hbase進行細粒度的數據訪問控制。通過操作Ranger控制台，管理員可以輕松的通過配置策略來控制用戶訪問HDFS文件夾、HDFS文件、資料庫、表、欄位許可權。這些策略可以為不同的用戶和組來設置，同時許可權可與hadoop無縫對接。
B. Mysql中什麼是存儲引擎
什麼是存儲引擎？
關系資料庫表是用於存儲和組織信息的數據結構，可以將表理解為由行和列組成的表格，類似於Excel的電子表格的形式。有的表簡單，有的表復雜，有的表根本不用來存儲任何長期的數據，有的表讀取時非常快，但是插入數據時去很差；而我們在實際開發過程中，就可能需要各種各樣的表，不同的表，就意味著存儲不同類型的數據，數據的處理上也會存在著差異，那麼。對於MySQL來說，它提供了很多種類型的存儲引擎，我們可以根據對數據處理的需求，選擇不同的存儲引擎，從而最大限度的利用MySQL強大的功能。這篇博文將總結和分析各個引擎的特點，以及適用場合，並不會糾結於更深層次的東西。我的學習方法是先學會用，懂得怎麼用，再去知道到底是如何能用的。下面就對MySQL支持的存儲引擎進行簡單的介紹。
MyISAM
在mysql客戶端中，使用以下命令可以查看MySQL支持的引擎。
復制代碼代碼如下:
show engines;
MyISAM表是獨立於操作系統的，這說明可以輕松地將其從Windows伺服器移植到Linux伺服器；每當我們建立一個MyISAM引擎的表時，就會在本地磁碟上建立三個文件，文件名就是表明。例如，我建立了一個MyISAM引擎的tb_Demo表，那麼就會生成以下三個文件：
1.tb_demo.frm，存儲表定義；
2.tb_demo.MYD，存儲數據；
3.tb_demo.MYI，存儲索引。
MyISAM表無法處理事務，這就意味著有事務處理需求的表，不能使用MyISAM存儲引擎。MyISAM存儲引擎特別適合在以下幾種情況下使用：
1.選擇密集型的表。MyISAM存儲引擎在篩選大量數據時非常迅速，這是它最突出的優點。
2.插入密集型的表。MyISAM的並發插入特性允許同時選擇和插入數據。例如：MyISAM存儲引擎很適合管理郵件或Web伺服器日誌數據。
InnoDB
InnoDB是一個健壯的事務型存儲引擎，這種存儲引擎已經被很多互聯網公司使用，為用戶操作非常大的數據存儲提供了一個強大的解決方案。我的電腦上安裝的MySQL 5.6.13版，InnoDB就是作為默認的存儲引擎。InnoDB還引入了行級鎖定和外鍵約束，在以下場合下，使用InnoDB是最理想的選擇：
1.更新密集的表。InnoDB存儲引擎特別適合處理多重並發的更新請求。
2.事務。InnoDB存儲引擎是支持事務的標准MySQL存儲引擎。
3.自動災難恢復。與其它存儲引擎不同，InnoDB表能夠自動從災難中恢復。
4.外鍵約束。MySQL支持外鍵的存儲引擎只有InnoDB。
5.支持自動增加列AUTO_INCREMENT屬性。
一般來說，如果需要事務支持，並且有較高的並發讀取頻率，InnoDB是不錯的選擇。
MEMORY
使用MySQL Memory存儲引擎的出發點是速度。為得到最快的響應時間，採用的邏輯存儲介質是系統內存。雖然在內存中存儲表數據確實會提供很高的性能，但當mysqld守護進程崩潰時，所有的Memory數據都會丟失。獲得速度的同時也帶來了一些缺陷。它要求存儲在Memory數據表裡的數據使用的是長度不變的格式，這意味著不能使用BLOB和TEXT這樣的長度可變的數據類型，VARCHAR是一種長度可變的類型，但因為它在MySQL內部當做長度固定不變的CHAR類型，所以可以使用。
一般在以下幾種情況下使用Memory存儲引擎：
1.目標數據較小，而且被非常頻繁地訪問。在內存中存放數據，所以會造成內存的使用，可以通過參數max_heap_table_size控制Memory表的大小，設置此參數，就可以限制Memory表的最大大小。
2.如果數據是臨時的，而且要求必須立即可用，那麼就可以存放在內存表中。
3.存儲在Memory表中的數據如果突然丟失，不會對應用服務產生實質的負面影響。
Memory同時支持散列索引和B樹索引。B樹索引的優於散列索引的是，可以使用部分查詢和通配查詢，也可以使用<、>和>=等操作符方便數據挖掘。散列索引進行「相等比較」非常快，但是對「范圍比較」的速度就慢多了，因此散列索引值適合使用在=和<>的操作符中，不適合在<或>操作符中，也同樣不適合用在order by子句中。
可以在表創建時利用USING子句指定要使用的版本。例如：
復制代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using hash (username),
primary key (id)
)engine=memory;
上述代碼創建了一個表，在username欄位上使用了HASH散列索引。下面的代碼就創建一個表，使用BTREE索引。
復制代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using btree (username),
primary key (id)
)engine=memory;
MERGE
MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表結構必須完全相同，盡管其使用不如其它引擎突出，但是在某些情況下非常有用。說白了，Merge表就是幾個相同MyISAM表的聚合器；Merge表中並沒有數據，對Merge類型的表可以進行查詢、更新、刪除操作，這些操作實際上是對內部的MyISAM表進行操作。Merge存儲引擎的使用場景。
對於伺服器日誌這種信息，一般常用的存儲策略是將數據分成很多表，每個名稱與特定的時間端相關。例如：可以用12個相同的表來存儲伺服器日誌數據，每個表用對應各個月份的名字來命名。當有必要基於所有12個日誌表的數據來生成報表，這意味著需要編寫並更新多表查詢，以反映這些表中的信息。與其編寫這些可能出現錯誤的查詢，不如將這些表合並起來使用一條查詢，之後再刪除Merge表，而不影響原來的數據，刪除Merge表只是刪除Merge表的定義，對內部的表沒有任何影響。
ARCHIVE
Archive是歸檔的意思，在歸檔之後很多的高級功能就不再支持了，僅僅支持最基本的插入和查詢兩種功能。在MySQL 5.5版以前，Archive是不支持索引，但是在MySQL 5.5以後的版本中就開始支持索引了。Archive擁有很好的壓縮機制，它使用zlib壓縮庫，在記錄被請求時會實時壓縮，所以它經常被用來當做倉庫使用。
存儲引擎的一些問題
1.如何查看伺服器有哪些存儲引擎可以使用？
為確定你的MySQL伺服器可以用哪些存儲引擎，執行如下命令：
復制代碼代碼如下:
show engines;
這個命令就能搞定了。
2.如何選擇合適的存儲引擎？
（1）選擇標准可以分為：
（2）是否需要支持事務；
（3）是否需要使用熱備；
（4）崩潰恢復：能否接受崩潰；
（5）是否需要外鍵支持；
然後按照標准，選擇對應的存儲引擎即可。
C. MySQL存儲引擎之Memory
首先創建表
我們能夠看到，表是不支持TEXT欄位的
我們再看下文件系統
只有一個保存表結構的文件
下面我們再看下錶的索引
首先，新建兩個索引
我們查看當前索引類型
存在兩個索引，一個為默認的，一個是指定的BTree。
接下來我們查看錶的狀態
Memory存儲引擎表和臨時表的區別
臨時表分兩類：系統使用臨時表，create temporary table 建立的臨時表。無論哪種表，只有當前session是可見的。而Memory表是所有線程都可以使用的。
系統使用臨時表又分為兩類：查過限制使用Myisam臨時表，未超過限制使用Memory表。
使用場景
注意一點是：Memory數據易丟失，所以要求數據可再生
memory存儲引擎是MySQL中的一類特殊的存儲引擎。其使用存儲在內存中的內容來創建表，而且所有數據也放在內存中。這些特性都與InnoDB，MyISAM存儲引擎不同。
OK，這里我們講解一些memory存儲引擎的文件存儲形式，索引類型，存儲周期和優缺點。
每個基於memory存儲引擎的表實際對應一個磁碟文件，該文件的文件名與表名相同，類型為frm類型。該文件只存儲表的結構，而其數據文件，都是存儲在內存中的，這樣有利於對數據的快速的處理，提高整個表的處理效率。
值得注意的是：伺服器需要有足夠的內存來維持memory存儲引擎的表的使用。如果不需要了，可以釋放這些內存，甚至可以刪除不需要的表。
Memory存儲引擎默認使用哈希(HASH)索引，其速度比使用B型樹(BTREE)索引快。如果我們需要使用B型樹索引，可以在創建索引時選擇使用。
這里來整理一個小的技巧：
Memory存儲引擎通常很少用到，至少我是沒有用到過。因為Memory表的所有數據都是存儲在內存上的，如果內存出現異常會影響到數據的完整性。
如果重啟機器或者關機，表中的所有數據都將消失，因此，基於Memory存儲引擎的表的生命周期都比較短，一般都是一次性的。
Memory表的大小是受到限制的，表的大小主要取決於2個參數，分別是max_rows和max_heap_table_size。其中，max_rows可以在創建表時指定，max_heap_table_size的大小默認為16MB，可以按需要進行擴大。
因此，其基於內存中的特性，這類表的處理速度會非常快，但是，其數據易丟失，生命周期短。基於其這個缺陷，選擇Memory存儲引擎時需要特別小心。
D. Mysql資料庫3種存儲引擎有什麼區別
MySQL常見的三種存儲引擎為InnoDB、MyISAM和MEMORY。其區別體現在事務安全、存儲限制、空間使用、內存使用、插入數據的速度和對外鍵的支持。具體如下：
1、事務安全：
InnoDB支持事務安全，MyISAM和MEMORY兩個不支持。
2、存儲限制：
InnoDB有64TB的存儲限制，MyISAM和MEMORY要是具體情況而定。
3、空間使用：
InnoDB對空間使用程度較高，MyISAM和MEMORY對空間使用程度較低。
4、內存使用：
InnoDB和MEMORY對內存使用程度較高，MyISAM對內存使用程度較低。
5、插入數據的速度：
InnoDB插入數據的速度較低，MyISAM和MEMORY插入數據的速度較高。
6、對外鍵的支持：
InnoDB對外鍵支持情況較好，MyISAM和MEMORY兩個不支持外鍵。
三種引擎特點如下：
1、InnoDB存儲引擎
InnoDB是事務型資料庫的首選引擎，支持事務安全表（ACID），其它存儲引擎都是非事務安全表，支持行鎖定和外鍵，MySQL5.5以後默認使用InnoDB存儲引擎。
InnoDB特點： 支持事務處理，支持外鍵，支持崩潰修復能力和並發控制。如果需要對事務的完整性要求比較高（比如銀行），要求實現並發控制（比如售票），那選擇InnoDB有很大的優勢。
如果需要頻繁的更新、刪除操作的資料庫，也可以選擇InnoDB，因為支持事務的提交（commit）和回滾（rollback）。
2、MyISAM存儲引擎
MyISAM基於ISAM存儲引擎，並對其進行擴展。它是在Web、數據倉儲和其他應用環境下最常使用的存儲引擎之一。MyISAM擁有較高的插入、查詢速度，但不支持事務，不支持外鍵。
MyISAM特點： 插入數據快，空間和內存使用比較低。如果表主要是用於插入新記錄和讀出記錄，那麼選擇MyISAM能實現處理高效率。如果應用的完整性、並發性要求比較低，也可以使用
3、MEMORY存儲引擎
MEMORY存儲引擎將表中的數據存儲到內存中，為查詢和引用其他表數據提供快速訪問。
MEMORY特點： 所有的數據都在內存中，數據的處理速度快，但是安全性不高。如果需要很快的讀寫速度，對數據的安全性要求較低，可以選擇MEMOEY。
它對表的大小有要求，不能建立太大的表。所以，這類資料庫只使用在相對較小的資料庫表。
(4)計算存儲引擎是什麼擴展閱讀：
mysql其餘不太常見的存儲引擎如下：
1、BDB： 源自Berkeley DB，事務型資料庫的另一種選擇，支持COMMIT和ROLLBACK等其他事務特性
2、Merge ：將一定數量的MyISAM表聯合而成一個整體，在超大規模數據存儲時很有用
3、Archive ：非常適合存儲大量的獨立的，作為歷史記錄的數據。因為它們不經常被讀取。Archive擁有高效的插入速度，但其對查詢的支持相對較差
4、Federated： 將不同的Mysql伺服器聯合起來，邏輯上組成一個完整的資料庫。非常適合分布式應用
5、Cluster/NDB ：高冗餘的存儲引擎，用多台數據機器聯合提供服務以提高整體性能和安全性。適合數據量大，安全和性能要求高的應用
6、CSV： 邏輯上由逗號分割數據的存儲引擎。它會在資料庫子目錄里為每個數據表創建一個.CSV文件。這是一種普通文本文件，每個數據行佔用一個文本行。CSV存儲引擎不支持索引。
7、BlackHole ：黑洞引擎，寫入的任何數據都會消失，一般用於記錄binlog做復制的中繼
E. MySQL簡單介紹——換個角度認識MySQL
1、InnoDB存儲引擎
Mysql版本>=5.5 默認的存儲引擎，MySQL推薦使用的存儲引擎。支持事務，行級鎖定，外鍵約束。事務安全型存儲引擎。更加註重數據的完整性和安全性。
存儲格式 : 數據，索引集中存儲，存儲於同一個表空間文件中。
InnoDB的行鎖模式及其加鎖方法： InnoDB中有以下兩種類型的行鎖：共享鎖（讀鎖： 允許事務對一條行數據進行讀取）和 互斥鎖（寫鎖： 允許事務對一條行數據進行刪除或更新）， 對於update，insert，delete語句，InnoDB會自動給設計的數據集加互斥鎖，對於普通的select語句，InnoDB不會加任何鎖。
InnoDB行鎖的實現方式： InnoDB行鎖是通過給索引上的索引項加鎖來實現的，如果沒有索引，InnoDB將通過隱藏的聚簇索引來對記錄加鎖。InnoDB這種行鎖實現特點意味著：如果不通過索引條件檢索數據，那麼InnoDB將對表中的所有記錄加鎖，實際效果跟表鎖一樣。
（1）在不通過索引條件查詢時，InnoDB會鎖定表中的所有記錄。
（2）Mysql的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果使用相同的索引鍵，是會出現沖突的。
（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，但都是通過行鎖來對數據加鎖。
優點：
1、支持事務處理、ACID事務特性；
2、實現了SQL標準的四種隔離級別（ 原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（Isolation ）和持續性（Durability ））；
3、支持行級鎖和外鍵約束；
4、可以利用事務日誌進行數據恢復。
5、鎖級別為行鎖，行鎖優點是適用於高並發的頻繁表修改，高並發是性能優於 MyISAM。缺點是系統消耗較大。
6、索引不僅緩存自身，也緩存數據，相比 MyISAM 需要更大的內存。
缺點：
因為它沒有保存表的行數，當使用COUNT統計時會掃描全表。
使用場景：
(1)可靠性要求比較高，或者要求事務；(2)表更新和查詢都相當的頻繁，並且表鎖定的機會比較大的情況。
2、 MyISAM存儲引擎
MySQL<= 5.5 MySQL默認的存儲引擎。ISAM：Indexed Sequential Access Method(索引順序存取方法)的縮寫，是一種文件系統。擅長與處理，高速讀與寫。
功能：
（1）支持數據壓縮存儲,但壓縮後的表變成了只讀表，不可寫；如果需要更新數據，則需要先解壓後更新。
（2）支持表級鎖定，不支持高並發；
（3）支持並發插入。寫操作中的插入操作，不會阻塞讀操作（其他操作）；
優點：
1.高性能讀取；
2.因為它保存了表的行數，當使用COUNT統計時不會掃描全表；
缺點：
1、鎖級別為表鎖，表鎖優點是開銷小，加鎖快；缺點是鎖粒度大，發生鎖沖動概率較高，容納並發能力低，這個引擎適合查詢為主的業務。
2、此引擎不支持事務，也不支持外鍵。
3、INSERT和UPDATE操作需要鎖定整個表；
使用場景：
(1)做很多count 的計算；(2)插入不頻繁，查詢非常頻繁；(3)沒有事務。
InnoDB和MyISAM一些細節上的差別：
1、InnoDB不支持FULLTEXT類型的索引，MySQL5.6之後已經支持（實驗性）。
2、InnoDB中不保存表的 具體行數，也就是說，執行select count() from table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count()語句包含 where條件時，兩種表的操作是一樣的。
3、對於AUTO_INCREMENT類型的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引。
4、DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
5、LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外鍵）的表不適用。
6、另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的范圍，InnoDB表同樣會鎖全表。
1．索引概述
利用關鍵字，就是記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分），建立與記錄位置的對應關系，就是索引。索引的關鍵字一定是排序的。索引本質上是表欄位的有序子集，它是提高查詢速度最有效的方法。一個沒有建立任何索引的表，就相當於一本沒有目錄的書，在每次查詢時就會進行全表掃描，這樣會導致查詢效率極低、速度也極慢。如果建立索引，那麼就好比一本添加的目錄，通過目錄的指引，迅速翻閱到指定的章節，提升的查詢性能，節約了查詢資源。
2．索引種類
從索引的定義方式和用途中來看：主鍵索引，唯一索引，普通索引，全文索引。
無論任何類型，都是通過建立關鍵字與位置的對應關系來實現的。索引是通過關鍵字找對應的記錄的地址。
以上類型的差異：對索引關鍵字的要求不同。
關鍵字：記錄的部分數據（某個欄位，某些欄位，某個欄位的一部分）。
普通索引,index：對關鍵字沒有要求。
唯一索引,unique index：要求關鍵字不能重復。同時增加唯一約束。
主鍵索引,primary key：要求關鍵字不能重復，也不能為NULL。同時增加主鍵約束。
全文索引,fulltext key：關鍵字的來源不是所有欄位的數據，而是從欄位中提取的特別關鍵詞。
PS：這里主鍵索引和唯一索引的區別在於：主鍵索引不能為空值，唯一索引允許空值；主鍵索引在一張表內只能創建一個，唯一索引可以創建多個。主鍵索引肯定是唯一索引，但唯一索引不一定是主鍵索引。
3.索引原則
如果索引不遵循使用原則，則可能導致索引無效。
（1）列獨立
如果需要某個欄位上使用索引，則需要在欄位參與的表達中，保證欄位獨立在一側。否則索引不會用到索引, 例如這條sql就不會用到索引:select * from A where id+1=10;
（2）左原則
Like：匹配模式必須要左邊確定不能以通配符開頭。例如:select * from A where name like '%小明%' ，不會用到索引，而select * from A where name like '小明%' 就可以用到索引（name欄位有建立索引），如果業務上需要用到'%小明%'這種方式,有兩種方法:1.可以考慮全文索引,但mysql的全文索引不支持中文；2.只查詢索引列或主鍵列,例如:select name from A where name like '%小明%' 或 select id from A where name like '%小明%' 或 select id,name from A where name like '%小明%' 這三種情況都會用到name的索引;
復合索引：一個索引關聯多個欄位，僅僅針對左邊欄位有效果，添加復合索引時，第一個欄位很重要，只有包含第一個欄位作為查詢條件的情況才會使用復合索引(必須用到建索引時選擇的第一個欄位作為查詢條件,其他欄位的順序無關),而且查詢條件只能出現and拼接,不能用or,否則則無法使用索引.
（3）OR的使用
必須要保證 OR 兩端的條件都存在可以用的索引，該查詢才可以使用索引。
（4）MySQL智能選擇
即使滿足了上面說原則，MySQL也能棄用索引，例如：select * from A where id > 1;這里棄用索引的主要原因：查詢即使使用索引，會導致出現大量的隨機IO，相對於從數據記錄的第一條遍歷到最後一條的順序IO開銷，還要大。
4.索引的使用場景
（1）索引檢索：檢索數據時使用索引。
（2）索引排序: 如果order by 排序需要的欄位上存在索引，則可能使用到索引。
（3）索引覆蓋: 索引擁有的關鍵字內容，覆蓋了查詢所需要的全部數據，此時，就不需要在數據區獲取數據，僅僅在索引區即可。覆蓋就是直接在索引區獲取內容，而不需要在數據區獲取。例如: select name from A where name like '小明%';
建立索引索引時，不能僅僅考慮where檢索，同時考慮其他的使用場景。（在所有的where欄位上增加索引，就是不合理的）
5.前綴索引
前綴索引是建立索引關鍵字一種方案。通常會使用欄位的整體作為索引關鍵字。有時，即使使用欄位前部分數據，也可以去識別某些記錄。就比如一個班級里，我要找王xx，假如姓王的只有1個人，那麼就可以建一個關鍵字為'王'的前綴索引。語法：Index `index_name` (`index_field`(N))使用index_name前N個字元建立的索引。
6.索引失效
（1） 應盡量避免在 where 子句中使用 != 或 > 操作符，否則將引擎放棄使用索引而進行全表掃描；
（2） 應盡量避免在 where 子句中使用 or 來連接條件，如果一個欄位有索引，一個欄位沒有索引，將導致引擎放棄使用索引而進行全表掃描；
（3） 應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描；
（4）應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描；如select id from t where num/2 = 100；
（5） 應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描；如：select id from t where substring(name,1,3) = 』abc』 ；
（6）應盡量避免在where子句中對欄位進行類型轉換，這將導致引擎放棄使用索引而進行全表掃描； 如果列類型是字元串，那一定要在條件中將數據使用引號引用起來,如select id from t where id = 1；如果id欄位在表設計中是varchar類型，那麼即使id列上存的是數字，在查詢時也一定要用varchar去匹配，sql應改為select id from t where id = '1'；
（7）應盡量避免在where子句中單獨引用復合索引里非第一位置的索引；
join 的兩種演算法：BNL 和 NLJ
NLJ（Nested Loop Join）嵌套循環演算法；以如下 SQL 為例：
select * from t1 join t2 on t1.a=t2.a
SQL 執行時內部流程是這樣的：
1. 先從 t1（假設這里 t1 被選為驅動表）中取出一行數據 X；
2. 從 X 中取出關聯欄位 a 值，去 t2 中進行查找，滿足條件的行取出；
3. 重復1、2步驟，直到表 t1 最後一行循環結束。
這就是一個嵌套循環的過程，如果在被驅動表上查找數據時可以使用索引，總的對比計算次數等於驅動表滿足 where 條件的行數。假設這里 t1、t2都是1萬行，則只需要 1萬次計算，這里用到的是Index Nested-Loops Join（INLJ，基於索引的嵌套循環聯接）。
如果 t1、t2 的 a 欄位都沒有索引，還按照上述的嵌套循環流程查找數據呢？每次在被驅動表上查找數據時都是一次全表掃描，要做1萬次全表掃描，掃描行數等於 1萬+1萬*1萬，這個效率很低，如果錶行數更多，掃描行數動輒幾百億，所以優化器肯定不會使用這樣的演算法，而是選擇 BNL 演算法；
BNLJ（Block Nested Loop Join）塊嵌套循環演算法；
1. 把 t1 表（假設這里 t1 被選為驅動表）滿足條件的數據全部取出放到線程的 join buffer 中；
2. 每次取 t2 表一行數據，去 joinbuffer 中進行查找，滿足條件的行取出，直到表 t2 最後一行循環結束。
這個演算法下，執行計劃的 Extra 中會出現 Using join buffer(Block Nested Loop)，t1、t2 都做了一次全表掃描，總的掃描行數等於 1萬+1萬。但是由於 joinbuffer 維護的是一個無序數組，每次在 joinbuffer 中查找都要遍歷所有行，總的內存計算次數等於1萬*1萬。另外如果 joinbuffer 不夠大放不下驅動表的數據，則要分多次執行上面的流程，會導致被驅動表也做多次全表掃描。
BNLJ相對於NLJ的優點在於，驅動層可以先將部分數據載入進buffer，這種方法的直接影響就是將大大減少內層循環的次數，提高join的效率。
例如：
如果內層循環有100條記錄，外層循環也有100條記錄，這樣的話，每次外層循環先將10條記錄放到buffer中，內層循環的100條記錄每條與這個buffer中的10條記錄進行匹配，只需要匹配內層循環總記錄數次即可結束一次循環（在這里，即只需要匹配100次即可結束），然後將匹配成功的記錄連接後放入結果集中，接著，外層循環繼續向buffer中放入10條記錄，同理進行匹配，並將成功的記錄連接後放入結果集。後續循環以此類推，直到循環結束，將結果集發給client為止。
可以發現，若用NLJ，則需要100 * 100次才可結束，BNLJ則需要100 / block_size * 100 = 10 * 100次就可結束,大大減少了循環次數。
JOIN 按照功能大致分為如下三類：
JOIN、STRAIGHT_JOIN、INNER JOIN（內連接,或等值連接）：取得兩個表中存在連接匹配關系的記錄。
LEFT JOIN（左連接）：取得左表（table1）完全記錄，即是右表（table2）並無對應匹配記錄。
RIGHT JOIN（右連接）：與 LEFT JOIN 相反，取得右表（table2）完全記錄，即是左表（table1）並無匹配對應記錄。
注意：mysql不支持Full join,不過可以通過UNION 關鍵字來合並 LEFT JOIN 與 RIGHT JOIN來模擬FULL join。
mysql 多表連接查詢方式，因為mysql只支持NLJ演算法,所以如果是小表驅動大表則效率更高；反之則效率下降；因此mysql對內連接或等值連接的方式做了一個優化,會去判斷join表的數據行大小,然後取數據行小的表為驅動表。
INNER JOIN、JOIN、WHERE等值連接和STRAIGHT_JOIN都能表示內連接，那平時如何選擇呢？一般情況下用INNER JOIN、JOIN或者WHERE等值連接，因為MySQL 會按照"小表驅動大表的策略"進行優化。當出現需要排序時，才考慮用STRAIGHT_JOIN指定某張表為驅動表。
兩表JOIN優化
a.當無order by條件時，根據實際情況，使用left/right/inner join即可，根據explain優化 ；
b.當有order by條件時，如select * from a inner join b where 1=1 and other condition order by a.col；使用explain解釋語句；
1）如果第一行的驅動表為a，則效率會非常高，無需優化；
2）否則，因為只能對驅動表欄位直接排序的緣故，會出現using temporary，所以此時需要使用STRAIGHT_JOIN明確a為驅動表，來達到使用a.col上index的優化目的；或者使用left join且Where條件中不含b的過濾條件，此時的結果集為a的全集，而STRAIGHT_JOIN為inner join且使用a作為驅動表。註：使用STRAIGHT_JOIN雖然不會using temporary，但也不是一定就能提高效率，如果a表數據遠遠超過b表，那麼有可能使用STRAIGHT_JOIN時比原來的sql效率更低，所以怎麼使用STRAIGHT_JOIN，還是要視情況而定。
在使用left join（或right join）時，應該清楚的知道以下幾點：
(1). on與 where的執行順序
ON 條件（「A LEFT JOIN B ON 條件表達式」中的ON）用來決定如何從 B 表中檢索數據行。如果 B 表中沒有任何一行數據匹配 ON 的條件,將會額外生成一行所有列為 NULL 的數據,在匹配階段 WHERE 子句的條件都不會被使用。僅在匹配階段完成以後，WHERE 子句條件才會被使用。它將從匹配階段產生的數據中檢索過濾。
所以我們要注意：在使用Left (right) join的時候，一定要在先給出盡可能多的匹配滿足條件，減少Where的執行。
(2).注意ON 子句和 WHERE 子句的不同
即使右表的數據不滿足ON後面的條件,也會在結果集拼接一條為NULL的數據行,但WHERE後面的條件不一樣,右表不滿足WHERE的條件,左表關聯的數據也會被過濾掉。
(3).盡量避免子查詢，而用join
往往性能這玩意兒，更多時候體現在數據量比較大的時候，此時，我們應該避免復雜的子查詢。
（1）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很多時候用 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)
（2）Update 語句，如果只更改1、2個欄位，不要Update全部欄位，否則頻繁調用會引起明顯的性能消耗，同時帶來大量日誌。
（3）join語句,MySQL裡面的join是用小表去驅動大表,而由於MySQL join實現的原理就是做循環，比如left join就是對左邊的數據進行循環去驅動右邊的表,左邊有m條記錄匹配,右邊有n條記錄那麼就是做m次循環,每次掃描n行數據,總掃面行數是m*n行數據。左邊返回的結果集的大小就決定了循環的次數,故單純的用小表去驅動大表不一定的正確的,小表的結果集可能也大於大表的結果集,所以寫join的時候盡可能的先估計兩張表的可能結果集,用小結果集去驅動大結果集.值得注意的是在使用left/right join的時候,從表的條件應寫在on之後,主表應寫在where之後.否則MySQL會當作普通的連表查詢；
（4）select count(*) from table；這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的；
（5）select * from t 這種語句要盡量避免，使用具體的欄位代替*，更有實際意義，需要什麼欄位就返回什麼欄位；
（6）數據量大的情況下，limit要慎用，因為使用limit m，n方式分頁時，mysql每次都是查詢前m+n條，然後舍棄前m條，所以m越大，偏移量越大，性能就越差。比如：select * from A limit 1000000,20這鍾，查詢效率就會非常低，當分頁的頁數大於一定的數量之後，就可以換種方式來分頁：select * from A a join （select id from A limit 1000000，20） b on a.id=b.id;
F. mysql的資料庫伺服器的默認存儲引擎是
mysql-5.1版本之前默認引擎是MyISAM，之後是innoDB。
MyISAM是非集聚引擎，支持全文索引;不支持事務;它是表級鎖;會保存表的具體行數。innoDB是集聚引擎，5.6以後才有全文索引;支持事務；它是行級鎖;不會保存表的具體行數。一般：不用事務的時候,count計算旁燃多的時候適合myisam引擎。對可靠性要求高就是用innodby引擎。
MySQL有9種存儲引擎，不同的引擎，適合不同的場景，我們最常用的，可能就是InnoDB，應該是從5.5開始，就成為了MySQL的默認存儲引擎。InnoDB是事務型資料庫的首選引擎，支持事務安全表(ACID)，支持行鎖定和卜洞外鍵型啟枯，InnoDB是默認的MySQL引擎。
G. mysql存儲引擎簡介及InnoDB和MyISAM的區別
MyISAM 和InnoDB 講解
InnoDB和MyISAM是許多人在使用MySQL時最常用的兩個表類型，這兩個表類型各有優劣，視具體應用而定。基本的差別為：MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，但是不提供事務支持，而InnoDB提供事務支持以及外部鍵等高級資料庫功能。
以下是一些細節和具體實現的差別：
◆1.InnoDB不支持FULLTEXT類型的索引。
◆2.InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from
table時，InnoDB要掃描一遍整個表來計算有多少行，但是MyISAM只要簡單的讀出保存好的行數即可。注意的是，當count(*)語句包含
where條件時，兩種表的操作是一樣的。
◆3.對於AUTO_INCREMENT類型的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引。
◆4.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。
◆5.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但是對於使用的額外的InnoDB特性(例如外鍵)的表不適用。
另外，InnoDB表的行鎖也不是絕對的，假如在執行一個SQL語句時MySQL不能確定要掃描的范圍，InnoDB表同樣會鎖全表，例如update table set num=1 where name like 「%aaa%」
兩種類型最主要的差別就是Innodb 支持事務處理與外鍵和行級鎖。而MyISAM不支持.所以MyISAM往往就容易被人認為只適合在小項目中使用。
作為使用MySQL的用戶角度出發，Innodb和MyISAM都是比較喜歡的，如果資料庫平台要達到需求：99.9%的穩定性，方便的擴展性和高可用性來說的話，MyISAM絕對是首選。
原因如下：
1、平台上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強不少的。
2、MyISAM的索引和數據是分開的，並且索引是有壓縮的，內存使用率就對應提高了不少。能載入更多索引，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小。
3、經常隔1，2個月就會發生應用開發人員不小心update一個表where寫的范圍不對，導致這個表沒法正常用了，這個時候MyISAM的優越性就體現出來了，隨便從當天拷貝的壓縮包取出對應表的文件，隨便放到一個資料庫目錄下，然後mp成sql再導回到主庫，並把對應的binlog補上。如果是Innodb，恐怕不可能有這么快速度，別和我說讓Innodb定期用導出xxx.sql機制備份，因為最小的一個資料庫實例的數據量基本都是幾十G大小。
4、從接觸的應用邏輯來說，select count(*) 和order by
是最頻繁的，大概能佔了整個sql總語句的60%以上的操作，而這種操作Innodb其實也是會鎖表的，很多人以為Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。
5、還有就是經常有很多應用部門需要我給他們定期某些表的數據，MyISAM的話很方便，只要發給他們對應那表的frm.MYD,MYI的文件，讓他們自己在對應版本的資料庫啟動就行，而Innodb就需要導出xxx.sql了，因為光給別人文件，受字典數據文件的影響，對方是無法使用的。
6、如果和MyISAM比insert寫操作的話，Innodb還達不到MyISAM的寫性能，如果是針對基於索引的update操作，雖然MyISAM可能會遜色Innodb,但是那麼高並發的寫，從庫能否追的上也是一個問題，還不如通過多實例分庫分表架構來解決。
7、如果是用MyISAM的話，merge引擎可以大大加快應用部門的開發速度，他們只要對這個merge表做一些select count(*)操作，非常適合大項目總量約幾億的rows某一類型(如日誌，調查統計)的業務表。
當然Innodb也不是絕對不用，用事務的項目就用Innodb的。另外，可能有人會說你MyISAM無法抗太多寫操作，但是可以通過架構來彌補。
H. mysql中的存儲引擎如何設置如果是將INNODB改成MYISAM怎樣改還有DOS中的MYSQL,怎樣保存資料庫,表等對象
1,mysql中的存儲引擎如何設置?------------默認是myisam，建表的時候也指定，例如： create table test(id int)engine=innodb;
2，如果是將INNODB改成MYISAM怎樣改?--------------------alter table test engine=myisam;
3,還有DOS中的MYSQL,怎樣保存資料庫,表等對象?-----------------在dos中執行 create database databasename; create table test(id int);這樣就生成了庫和表；對應的系統文件在mysql的安裝目錄的data下，資料庫名對應一個文件夾。比如 create database testdb，那麼就能在data目錄下找到testdb目錄；表等對象的文件要看具體的引擎，如果是myisam引擎，那麼就會有三個文件，test.frm,test.myi,test.myd三個，innodb的話只有一個test.frm結構文件，數據和索引文件都在 ibdata1表空間里。
4，PHP如何和MYSQL連接?是否非要輸入代碼?有沒有別的簡單方法如UI式設置-------------------需要你寫連接信息，網上給你找了個php連接mysql的例子，你參考下
<?php
$mysql_server_name='localhost'; //改成自己的mysql資料庫伺服器
$mysql_username='root'; //改成自己的mysql資料庫用戶名
$mysql_password='198791'; //改成自己的mysql資料庫密碼
$mysql_database='mydb'; //改成自己的mysql資料庫名
$conn=mysql_connect ($mysql_server_name,$mysql_username,$mysql_password,$mysql_database); //從這句開始向下解釋
$sql='insert into book (name,pwd) values ("ggg","ggg");';
//這是一個SQL語句: 向book表中插入一條記錄
mysql_query($sql);
//執行SQL語句
mysql_select_db($mysql_database,$conn); //選擇上面表所在的資料庫(這一句應該在上面一句的前面執行)
$result=mysql_query($sql); //這一句完全是多餘的,和上面的那一個是一樣的!
mysql_close($conn); //關閉資料庫連接
echo "Hello!操作成功！"; //顯示提示信息
?>