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

標籤：

在本機電腦無法啟動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

 

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

 

   第一次設定的efault-storage-engine與第二次設定的值不一樣，可能會導致 

1：發現無法選擇添加事務支援資料引擎InnoDB

2：可能會說不支援InnoDB等

 

解決方案：

 刪除：ib_logfile0

          ib_logfile1

          ibdata1

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

 

 

 

這段時間在看《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

 

 

 

 

串連：

http://www.javaeye.com/topic/211951

 

 

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