本地無法啟動MySQL服務,報的錯誤：1067，進程意外終止---解決

原文鏈接：http://blog.csdn.net/shenhonglei1234/article/details/5928873

在本地計算機無法啟動MYSQL服務錯誤1067進程意外終止這種情況一般是my.ini文件配置出錯了

首先找到這個文件：默認安裝路徑

C:/Program Files/MySQL/MySQL Server 5.1/my.ini

打開此文件找到：default-storage-engine=INNODB?? 大概在84行。

將default-storage-engine的值改為：MYISAM，這個時候，MYSQL服務可以啟動。

但是還有問題：因為以前你創建的那些數據庫還是存在的(如果沒有刪除)，

默認路徑：

C:/Documents and Settings/All Users/Application Data/MySQL/MySQL Server 5.1/data

這時可能會出來這種問題：

?? 第一次設置的default-storage-engine與第二次設置的值不一樣，可能會導致?

1：發現無法選擇添加事務支持數據引擎InnoDB

2：可能會說不支持InnoDB等

解決方法：

?刪除：ib_logfile0

????????? ib_logfile1

?????? ?? ibdata1

重啟服務，再次生成就OK了

?若仍沒有解決，請參考：

MySQL手動安裝： http://blog.csdn.net/dmtnewtons/article/details/9666995

MySQL卸載：http://blog.csdn.net/dmtnewtons/article/details/9475629

這段時間在看《High Performance MySQL》，看到存儲引擎這個地方感到很多細節比較陌生，所以總結小記一些

為了適應各種不同的運行環境，MYSQL提供了多種不同的存儲引擎（Storage Engine ）,在應用程序開發這個層面上，開發者可以根據不同的需求選擇適合的Storage Engine 方案，更為靈活的是，你可以根據每張表將要存儲數據的特點，選擇不同的Storage Engine,也就是說，在一個MYSQL數據庫中，可以混合使用多種不同的Storage Engine

首先小瞥一下MySQL的體系結構，在最高抽象層度下，可以用Garlan & Shaw的分層結構體系來表示（左）

其中應用層為所有RDBMS用戶提供用戶接口，邏輯層包括了所有核心功能的實現，物理層則負責將數據存儲在硬件設備上。

圖中右側更為具體的描述了邏輯層的組成，查詢處理子系統、事務管理子系統、恢復管理子系統和存儲管理子系統共同組成了MySQL的邏輯層。相信Storage Engine的位置是在Storage Management處，既Storage Engine屬于Storage Management子系統的一部分

為了讓思路更清晰一些，下面給出一幅比較全面的體系結構圖（或更確切的說是流程圖，只是忽略了反饋）

上面三幅圖來自于一篇非官方（不保證百分百的正確）的MySQL體系結構的報告，與《High Performance MySQL》一書中給出的MySQL大體結構（下圖,基本對應于Logic Layer，從第一幅圖右側可以看出MySQL logic layer同樣遵從分層體系結構）還是比較吻合的。

連接上圖中第二層和第三層之間的接口是并不針對任何存儲引擎的單一API,.大概由20個基本的類似“啟動事務，返回結果集”等函數組成。存儲引擎并不處理SQL，相互之間也不通信，它們的任務只是簡單的響應高層傳來的請求。

存儲引擎各自的一些特點

上面提到的四種存儲引擎都有各自適用的環境，這取決于它們獨有的一些特征。主要體現在性能、事務、并發控制、參照完整性、緩存、故障恢復，備份及回存等幾個方面

目前比較普及的存儲引擎是MyISAM和InnoDB.而MyISAM又是絕大部分Web應用的首選。MyISAM與InnoDB的主要的不同點在于性能和事務控制上。

MyISAM是早期ISAM(Indexed Sequential Access Method,我現在用的MySQL5.0已經不支持ISAM了）的擴展實現，ISAM被設計為適合處理讀頻率遠大于寫頻率這樣一種情況，因此ISAM以及后來的MyISAM都沒有考慮對事物的支持，排除了TPM，不需要事務記錄，ISAM的查詢效率相當可觀，而且內存占用很少。MyISAM在繼承了這類優點的同時，與時俱進的提供了大量實用的新特性和相關工具。例如考慮到并發控制，提供了表級鎖，雖然MyISAM本身不支持容錯，但可以通過myisamchk進行故障恢復。而且由于MyISAM是每張表使用各自獨立的存儲文件（MYD數據文件和MYI索引文件），使得備份及恢復十分方便（拷貝覆蓋即可），而且還支持在線恢復。

所以如果你的應用是不需要事務，處理的只是基本的CRUD操作，那么MyISAM是不二選擇

InnoDB被設計成適用于高并發讀寫的情況.使用MVCC(Multi-Version Concurrency Control)以及行級鎖來提供遵從ACID的事務支持。InnoDB支持外鍵參照完整性，具備故障恢復能力。另外 InnoDB的性能其實還是不錯的，特別是在處理大數據量的情況下,用官方的話說就是： InnoDB的CPU效率是其他基于磁盤的關系數據庫存儲引擎所不能比的。不過InnoDB的備份恢復要麻煩一點，除非你使用了4.1以后版本提供的Mulit-tablespace支持，因為InnoDB和MyISAM不同，他的數據文件并不是獨立對應于每張表的。而是使用的共享表空間，簡單的拷貝覆蓋方法對他不適用，必須在停掉MYSQL后對進行數據恢復。使用Per-Table Tablespacesd，使其每張表對應一個獨立的表空間文件，則情況要簡單很多。

一般來說，如果需要事務支持，并且有較高的并發讀寫頻率，InnoDB是不錯的選擇。要是并發讀寫頻率不高的話，其實可以考慮BDB,但由于在MySQL5.1及其以后版本中，將不再提供BDB支持。這個選項也就沒有了

至于Heap和BDB（Berkeley DB），相對來說，普及率不如前兩種，但在有些情況下，還是挺適用的

Heap存儲引擎就是將數據存儲在內存中，由于沒有磁盤I./O的等待，速度極快。但由于是內存存儲引擎，所做的任何修改在服務器重啟后都將消失。
?
Heap挺適合做測試的時候使用

BDB是MySQL第一款事務安全的存儲引擎。在Berkeley DB database library的基礎上建立，同樣是事務安全的，但BDB的普及率顯然不及InnoDB，因為大多數在MySQL中尋找支持事務的存儲引擎的同時也在找支持MVCC或是行級鎖定存儲引擎，而BDB只支持Page-level Lock。

附上一張《High Performance MySQL》中的各存儲引擎的特性表

Attribute	MyISAM	Heap	BDB	InnoDB
Transactions	No	No	Yes	Yes
Lock granularity	Table	Table	Page (8 KB)	Row
Storage	Split files	In-memory	Single file per table	Tablespace(s)
Isolation levels	None	None	Read committed	All
Portable format	Yes	N/A	No	Yes
Referential integrity	No	No	No	Yes
Primary key with data	No	No	Yes	Yes
MySQL caches data records	No	Yes	Yes	Yes
Availability	All versions	All versions	MySQL-Max	All Versions