Major difference between two storage engine MyISAM and INNODB

The major differences between these two storage engines are :

• InnoDB supports transactions which is not supported by tables which use MyISAM storage engine.
• InnoDB has row-level locking, relational integrity i.e. supports foreign keys, which is not possible in MyISAM. MyISAM can do only a table-level lock.
• InnoDB ‘s performance for high volume data cannot be beaten by any other storage engines available.
• InnoDB offers ACID transcations, row level locking, foreign key constraints, automatic crash recovery, table compression (read/write).
• MyISAM offers fast count(*), full text indexing, smaller disk footprint, very high table compression ( read only ).
• innodb is journaled, and can recover from crashes where myisam can't, much like NTFS vs FAT file systems. 
• In MyISAM the main mechanism used is the key cache. It only caches index pages from .MYI files
• In InnoDB the main mechanism used is the InnoDB Buffer Pool. It caches data and index pages from InnoDB tables accessed.

mysql crashed

Issue : mysql crashed after server reboot, mysql start failing every 10-15 minutes with following error:

…..

InnoDB: Doing recovery: scanned up to log sequence number 22 1183672832

InnoDB: Doing recovery: scanned up to log sequence number 22 1188915712

InnoDB: Doing recovery: scanned up to log sequence number 22 1194158592

InnoDB: Doing recovery: scanned up to log sequence number 22 1199401472

InnoDB: Doing recovery: scanned up to log sequence number 22 1204644352

InnoDB: Doing recovery: scanned up to log sequence number 22 1209887232

Here is the solution  work out for me:

Enable #innodb_force_recovery=1 in my.cnf

Again failed with same error

Set innodb_force_recovery=2 failed

innodb_force_recovery=3 failed

innodb_force_recovery=4 successful

mysql started successfuly however few tables got corrupted, see the error logs:

090505 14:07:34 [ERROR] /usr/sbin/mysqld: Table './db_2_1/userclients' is marked as crashed and should be repaired

090505 14:07:34 [Warning] Checking table:   './db_2_1/userclients'

090505 14:07:34 [ERROR] 1 client is using or hasn't closed the table properly

090505 14:08:47 [ERROR] /usr/sbin/mysqld: Table './db_2_1/smsrecord' is marked as crashed and should be repaired

090505 14:08:47 [Warning] Checking table:   './db_2_1/smsrecord'

090505 14:08:47 [ERROR] 1 client is using or hasn't closed the table properly

090505 14:12:26 [Note] Slave I/O thread killed while reading event

now repair the tables

root#mysql>repair table table_name

 

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

Whenever a INSERT/UPDATE/DELETE query have LIMIT clause without ORDER BY clause on master server where replication type is STATEMENT,  such warnings can be seen in mysql error logs.
To avoid such warning we either have to satisfy the query with proper syntax or change the replication type to ROW from STATEMENT.
Here is detailed explanation http://www.dbasquare.com/2012/04/17/why-a-statement-can-be-unsafe-when-it-uses-limit-clause/