Local failed to start MySQL service, reported error: 1067, process terminated unexpectedly---resolved

The local computer fails to start the MySQL service error 1067 process terminated unexpectedly this situation is generally a My.ini file configuration error

First find this file: Default installation path

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

Open this file found: Default-storage-engine=innodb is probably in line 84.

Change the value of Default-storage-engine to: MYISAM, this time, the MySQL service can be started.

But there's still a problem: because the databases you created before are still there (if not deleted),

Default path:

C:/Documents and Settings/all users/application data/mysql/mysql Server 5.1/data

This problem may come up at this point:

The Efault-storage-engine set for the first time is not the same as the value of the second setting, which may cause

1: Found Unable to select Add transaction support Data Engine InnoDB

2: May say does not support InnoDB etc.

Workaround:

Delete: Ib_logfile0

Ib_logfile1

Ibdata1

Restart the service and make the achievement OK again

This time in watching "High performance MySQL", see the storage engine this place feel a lot of details are unfamiliar, so summarize small remember some

In order to adapt to a variety of operating environments, MySQL offers a variety of storage engines (Storage engine), at the level of application development, developers can choose the right Storage Engine solution according to different needs, more flexible is, You can choose a different storage engine based on the characteristics of each table that will store the data, that is, in a MySQL database, you can mix and use a variety of different storage engine

First, a little glimpse of MySQL's architecture, at the highest level of abstraction, can be represented by Garlan & Shaw's layered architecture (left)

The application layer provides the user interface for all RDBMS users, and the logic layer includes the implementation of all core functions, and the physical layer is responsible for storing the data on the hardware device.

The right side of the graph describes the composition of the logical layer, and the query processing subsystem, the transaction management subsystem, the recovery management subsystem, and the storage management subsystem together compose the logical layer of MySQL. Believe that storage engine is located at storage management, storage engine is part of storage management subsystem

To make the idea clearer, here is a more comprehensive architecture diagram (or rather a flowchart, just ignoring feedback).

The above three images are from an unofficial (not guaranteed hundred correct) MySQL architecture report, and the MySQL general structure given in the book "High Performance MySQL" (basically corresponds to the logic Layer, from the right side of the first picture to see MySQL The logic layer also conforms to the hierarchical architecture) or is quite consistent.

The interface between the second and third tiers of the connection is not a single API for any storage engine. Probably consists of 20 basic functions like "Start transaction, return result set". The storage engine does not handle SQL and does not communicate with each other, their task is simply to respond to requests from the top.

some features of the storage engine

The four storage engines mentioned above have their respective environments, depending on their unique characteristics. Mainly embodied in performance, transaction, concurrency control, referential integrity, caching, failure recovery, backup and back-up, and several other aspects


At present, the more popular storage engine is MyISAM and InnoDB. And MyISAM is the first choice for most Web applications. The main difference between MyISAM and InnoDB is in performance and transaction control.

MyISAM is an early ISAM (Indexed sequential Access Method, I'm using an extended implementation of MySQL5.0 that doesn't support ISAM anymore, and ISAM is designed to handle a situation where read frequency is much larger than write frequency, so ISAM and later MyISAM do not consider support for things, eliminate the TPM, do not require transaction logging, the ISAM query efficiency is considerable, and the memory accounts for With little. MyISAM, while inheriting this kind of advantage, has provided a lot of practical new features and related tools with the times. For example, given concurrency control, table-level locks are provided, although MyISAM itself does not support fault tolerance, but can be myisamchk for failback. And because MyISAM is each table using its own separate storage files (myd data files and myi index files), it makes backup and recovery very convenient (copy overwrite), but also supports online recovery.

So if your application does not require transactions and is only dealing with basic crud operations, then MyISAM is the choice

The InnoDB is designed for high concurrency and read-write scenarios. Use MVCC (multi-version Concurrency Control) and row-level locks to provide acid-compliant transactional support. INNODB supports foreign key referential integrity and is capable of failure recovery. In addition InnoDB performance is actually good, especially in the case of large data processing, in the official words: InnoDB CPU efficiency is other disk-based relational database storage engine can not be compared. But InnoDB backup recovery is a bit cumbersome, unless you use the Mulit-tablespace support provided by version 4.1, because InnoDB and MyISAM are different, his data files do not correspond to each table independently. Instead of using a shared table space, a simple copy overwrite method does not apply to him and must be restored after the MySQL has been stopped. It is much easier to use per-table tablespacesd to make each table correspond to a separate tablespace file.

In general, InnoDB is a good choice if transaction support is required and there is a high frequency of concurrent read and write. If the concurrent read and write frequency is not high, actually may consider BDB, but because in MySQL5.1 and later releases, will not provide BDB support. There's no such option.

As for the heap and BDB (Berkeley DB), the penetration rate is not as good as the first two, but in some cases it is quite applicable.

The heap storage engine is the data stored in memory, because there is no disk i./o waiting, very fast. However, because it is a memory storage engine, any modifications made will disappear after the server restarts.

The heap is suitable for testing when used


BDB is MySQL's first transaction-safe storage engine. Built on the basis of the Berkeley DB database, it is also transaction-safe, but BDB's penetration rate is obviously less than InnoDB, as most of the storage engines that support transactions in MySQL are looking for support for MVCC or row-level lock-out storage engines. and BDB only supports Page-level Lock.

Attach a feature sheet for each of the storage engines in 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

Connection:

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

Local failed to start MySQL service, reported error: 1067, process terminated unexpectedly---resolved