InnoDB is the better engine and is the one I will be using in all of my projects. InnoDB is faster and more resilient to errors.
These article brings together all of my InnoDB notes which were built while trying to get my head around the different SQL engines (InnoDB vs MyISAM) and which one to use.
- MyISAM to InnoDB
- WordPress specifies no table type in the create statements, so it uses MySQL's default table engine which is InnoDB from version 5.5 onwards.
- Which is Better MySQL Engine for WordPress : MyISAM or InnoDB
- This article explains with clear thought that InnoDB is better and why while using WordPress as a focus.
- This article also has a few SQL scripts for checking and changing.
- Your server defaults determine the database table format because WordPress does not specify the engine to use. This is a choice the developers have made.
- InnoDB is capable of taking advantage of multiple cores, but MyISAM can only use one core.
- InnoDB likes RAM.
- InnoDB can recover better from a crash and is more stable in general.
- If improperly set up InnoDB can lead to more frequent crashes leading to WordPress Database Connection Error.
- InnoDB has referential integrity which involves supporting foreign keys (RDBMS) and relationship constraints.
- InnoDB supports transactions, which means you can rollback.
- InnoDb is the winner in performance for the average user.
- MyISAM is easier to backup raw while running for server snapshots, where InnoDB data may get corrupted in backups performed in that way – you need manual checking.
- Switching the format of database tables to InnoDB will decrease overall CPU load on the server, the site may become faster. Although there are some risks of crashes, it is generally accepted that InnoDB is the better engine for WordPress databases.
- mysql - MyISAM versus InnoDB - Stack Overflow - A good discussion.
- JV-LinkDirectory 4.8 Dev Update: Database Level Changes
- JV-LD has been using MyISAM as the primary MySQL engine type in all the versions till now. We are making a conscious shift to InnoDB engine type with JV-LD 4.8.
- InnoDB is one of the several engine types that MySQL provides and is a very powerful, performance oriented engine.
- InnoDB provides transactional (OLTP - Online Transaction Processing) capabilities, that enable integrity of transactions to be maintained.
- With InnoDB, JV-LD will now use several foreign keys with in the tables, which maintain relationships between tables in a more efficient way and speed up the execution.
- InnoDB is also the preferred engine, as your directory grows, as it gives you better locking mechanisms unlike MyISAM which does row level locking only.
- InnoDB is a largely ACID (Atomicity, Consistency, Isolation, Durability) engine, built to guarantee consistency and durability. It does this through a transaction log (with the option of a two-phase commit if you have the binary log enabled), a double-write buffer and automatic checksumming and checksum validation of database pages. These safety measures not only prevent corruption on "hard" shutdowns, but can even detect hardware failure (such as memory failure/corruption) and prevent damage to your data
- MySQL :: MySQL 8.0 Reference Manual :: 15.6.1.5 Converting Tables from MyISAM to InnoDB
- If you have MyISAM tables that you want to convert to InnoDB for better reliability and scalability, review the following guidelines and tips before converting.
- This article has many explanations of the different InnoDB settings.
- MySQL :: MySQL 5.6 Reference Manual :: 14.6.1.5 Converting Tables from MyISAM to InnoDB - Just the same document for MySQL 5.6
- WordPress: Choosing mySQL Database Engine: myISAM or InnoDB?
- Since MySQL 5.5 InnoDB is the default engine.
- InnoDB supports transactions, it is very fast in insert or update operations because it supports row locking allowing for multiple operations over same table and it supports foreign keys for table relations.
- If you have powerful server with a lot of memory, you will not notice any slowdowns (if InnoDB is set properly), and for many operations you may notice speed improvements.
- For normal websites, with no big traffic, engine is not that important. Speed issues comes into play if you have a lot of traffic on your website. I think the speed difference now is always noticeable especially as websites with CMS get more complicated.
- InnoDB vs MyISAM - Faster WordPress - Friday Next
- Choosing the Right Storage Engine - MariaDB Knowledge Base
- A high-level overview of the main reasons for choosing a particular storage engine.
- InnoDB is a good general transaction storage engine, and, from MariaDB 10.2, the best choice in most cases. It is the default storage engine from MariaDB 10.2.
- Enhance WordPress Performance by Moving from MyISAM to Innodb
- The Ultimate Developer's Guide to the WordPress Database
- A storage engine is the part of the database that is responsible for reading and writing data. Since MySQL 5.5 the default storage engine has been InnoDB. It is the most commonly used storage engine, as it has row-level locking instead of full table-level locking (super important when you’re doing a mysqldump export/backup), has support for transactions (allowing you to commit and rollback SQL statements), and has full support for foreign keys and relationship constraints.
- MyISAM was the storage engine used in the past by WordPress and you might still have older WordPress sites running on it. Some sites might even have a mix of tables using both MyISAM and InnoDB storage engines.
- WordPress Database Optimization - Support Center | WP Engine
- WP Engine only supports the InnoDB table storage engine and any tables using MyISAM will be converted automatically. The storage engine your site uses will make a big difference in performance due to the way they write data and use server resources, and we’ve found that InnoDB consistently performs better.
- MyISAM performs just fine for database read operations, but when it comes to writing or updating data, the entire table is locked until the process is complete. This prevents any other read/write operations from starting in that table until that individual process is done. InnoDB only locks the single row being written to, freeing up the rest of the table for simultaneous operations.
- Another big difference is the way both storage engines interact with memory on the server. There is a specific pool of Memory called the InnoDB Buffer Pool to be used by InnoDB tables. Tables which use MyISAM are not able to use this Memory pool, meaning they write to disk (swap) instead of using the database memory.
- database - WordPress site uses MyISAM, should I switch to InnoDB necessary? - WordPress Development Stack Exchange
- MyISAM could not be backed up while the database is running either. Databases generally cannot be backed up by running using a naive method like taring up the files. The data has to be static / point-in-time consistent. So if you take a snapshot and back up a snapshot, that is fine.
- With InnoDB you can also use xtrabackup, which is faster to back up and much, much faster to restore than mysqldump. You can also use mysqldump --single-transaction to back up without locking the tables (mysqldump with MyISAM results in all tables being locked during the backup process).
- WordPress Plugins (MyISAM to InnoDB)
- Simple MyISAM to InnoDB – WordPress plugin | WordPress.org - I have used this and it just works.
- Use InnoDB – WordPress plugin | WordPress.org
- Not updated in a while but the description has the following note
- The InnoDB storage engine locks tables (when needed) on a single row level, while MyISAM does this on the entire table level, this is less effective and leads to WordPress slow-ness when working with highly loaded sites or large options table
- Conversion Scripts / Tutorials
- MyISAM to InnoDB | rjweb.org
- You have decided to change some table(s) from MyISAM to InnoDB. That should be as simple as ALTER TABLE foo ENGINE=InnoDB. But you have heard that there might be some subtle issues.
- This is describes the possible issues and what do do about them
- Converting MySQL Tables From MyISAM to InnoDB | Pantheon Docs - A very well written script with feedback.
- k2_items innodb - Community Forum - JoomlaWorks
- As recommended but Fotis at Joomla K2 for converting K2 tables.
- On a production server, InnoDB is much faster for practical reasons.
- Convert Tables from MyISAM 2 InnoDB 4 Performance? - Community Forum - JoomlaWorks - Realted to converting K2 database.
- k2_items innodb - Community Forum - JoomlaWorks
- mysql - How to convert all tables from MyISAM into InnoDB? - Stack Overflow
- How to change the database engine of a MySQL database table? - SiteGround KB
- Command to change a single table
-
ALTER TABLE my_table ENGINE = InnoDB;
- Converting MyISAM to InnoDB - Joomla! Forum - community, help and support - The last post has the script.
- Converting WordPress database tables from MyIASM to InnoDB – Paul Stenning
- MySQL Storage Engine - How to Convert MyISAM to InnoDB | Kinsta - A great and easy to read tutorial
- Converting WordPress Database Tables from MyISAM to InnoDB with WP-CLI •
- This simple script uses PHP to change your databaase tables from MyISAM to InnoDB.
<?php // connect your database here first $dbhost = 'localhost'; $dbuser = '*********'; $dbpass = '*********'; $dbname = '*********'; $conn = mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql'); mysql_select_db($dbname); // Actual code starts here $sql = "SHOW tables"; $rs = mysql_query($sql); while($row = mysql_fetch_array($rs)) { $tbl = $row[0]; $sql = "ALTER TABLE $tbl ENGINE=INNODB"; mysql_query($sql); } ?>
- Conversion MyISAM To InnoDB / WordPress Agentur JoeWP - This uses phpMyAdmin for the conversion.
- How to change your MyISAM DB to InnoDB using phpMyAdmin | MODX
- InnoDB is a more robust and better database table type for modern applications like MODX Revolution compared to the older MyISAM table type. With InnoDB, you should see improvements in platform I/O, your sites should perform better and faster, and they should better survive database hiccups that can occur, too. MODX Revolution 2.6 will default to InnoDB for new installations, if supported.
- Converting to InnoDB from MyISAM tables using the Command Line | MODX
- This is a slightly more advanced companion to our [previous tutorial to convert to InnoDB using phpMyAdmin](blog/convert-myisam-to-innodb-with-phpmyadmin). It is especially useful for power users and larger databases that may fail conversion when using a GUI web app.
- MyISAM to InnoDB | rjweb.org
- What is the purpose of ibdata1, ib_logfile0, ib_logfile1
- what is the purpose of ibdata1,ib_logfile0,ib_logfile1 - Other MySQL® Questions - Percona Community Forum
- Those are the files where the actual data, indexes and the innodb log are stored for all innodb databases
- If you’re using the innodb_file_per_table option, then each InnoDB table gets its own .ibd file, so you can recover freed-up space in a table by rebuilding just that one table.
- The easiest way to rebuild an InnoDB table is to run the command, “ALTER TABLE tablename ENGINE=InnoDB;”. However, this will build the new copy of the table on disk before dropping the old one, so you’ll need to have enough free disk space to keep the entire second copy of the table.
- If you’re tight on disk space on the database server (which is probably why you want to free up the space trapped in the InnoDB tablespace in the first place), then you can mysqldump the table to another machine with more free space and then re-import it back into the database server. It’s still a pain to have to do that, but it’s a lot better than having to dump ALL of your tables.
- Does mysql configuration options accepts - instead of _?
- Does mysql configuration options accepts - instead of _? - Database Administrators Stack Exchange
- Within option names, dash (-) and underscore (_) may be used interchangeably. For example, --skip-grant-tables and --skip_grant_tables are equivalent. (However, the leading dashes cannot be given as underscores.)
- This applies to options when you use them in option files, as well as command-line flags.
- However, when using option variables in SQL queries, like in SET GLOBAL read_only=ON, you must use underscores only. Even putting the variable in back-ticks doesn't allow you to use hyphens.
- Hyphens in column names in MySQL DB | Newbedev
- Hyphens are a big problem because if you end up mapping a column name to a variable, most languages do not like to have hyphens inside variable names.
- I dont know which is better to update my notes with.
- Does mysql configuration options accepts - instead of _? - Database Administrators Stack Exchange
- innodb_file_per_table option
- innodb_file_per_table is enabled by default in MariaDB.
- With this option enabled you can actually shrink .ibd tables.
- mysql - Why using innodb_file_per_table? - Database Administrators Stack Exchange - A good discussion.
- Reasons to use innodb_file_per_table – code.openark.org - A lot of aspects are discussed here.
- With this parameter set, a .ibd file is created per table. What we get is this:
- Tablespace is not shared among different tables, and certainly not among different schemes.
- Each file is considered a tablespace of its own.
- Again, tablespace never reduces in size.
- It is possible to regain space per tablespace.
- With this parameter set, a .ibd file is created per table. What we get is this:
- innodb - MySql - changing innodb_file_per_table for a live db - Database Administrators Stack Exchange - Several methods on changing to seperate table files.
- InnoDB File-Per-Table Tablespaces - MariaDB Knowledge Base
- When you create a table using the InnoDB storage engine, data written to that table is stored on the file system in a data file called a tablespace. Tablespace files contain both the data and indexes.
- When innodb-file-per-table=ON is set, InnoDB uses one tablespace file per InnoDB table. These tablespace files have the .ibd extension. When innodb_file_per_table=OFF is set, InnoDB stores all tables in the InnoDB system tablespace.
- MySQL InnoDB - innodb_file_per_table cons? - Server Fault
- By default MySQL InnoDB stores all tables of all DBs in one global file. You can change this by setting innodb_file_per_table in the config, which then creates one data file for each table. I am wondering why innodb_file_per_table is not enabled by default. Are there downsides to using it?
- Once innodb_file_per_table is put in place, and new InnoDB tables can be shrunk using ALTER TABLE <innodb-table-name> ENGINE=InnoDB'; This will shrink new .ibd files GUARANTEED.
- If you run ALTER TABLE <innodb-table-name> ENGINE=InnoDB'; on an InnoDB table created before you used innodb_file_per_table, it will yank the data and indexes for that table out of the ibdata1 file and store it in a .ibd file, This will leave a permanent pigeon whole in the ibdata1 that can never be reused.
- Complete Instructions on how to convert current data aswell.
- By default MySQL InnoDB stores all tables of all DBs in one global file. You can change this by setting innodb_file_per_table in the config, which then creates one data file for each table. I am wondering why innodb_file_per_table is not enabled by default. Are there downsides to using it?
- MySQL - Converting to Per Table Data for InnoDB • Conetix
- MySQL :: MySQL 5.6 Reference Manual :: 14.6.3.2 File-Per-Table Tablespaces
- Repairing Database
- Tutorial - InnoDB Corruption Repair Guide | cPanel Forums
- This basic guide goes over some of the methods you can use to deal with some of the most common InnoDB corruption issues, from start to finish. It is fairly lengthy.
- InnoDB Recovery Modes - MariaDB Knowledge Base
- Tutorial - InnoDB Corruption Repair Guide | cPanel Forums
- Configuring / Tuning / Performance
- Configuring MariaDB for Optimal Performance - MariaDB Knowledge Base
- InnoDB or XtraDB is normally the default storage engine with MariaDB.
- You should set innodb_buffer_pool_size to about 80% of your memory. The goal is to ensure that 80 % of your working set is in memory!
- This makes other configuration recommendations
- Configuring MariaDB with Option Files - MariaDB Knowledge Base
- You can configure MariaDB to run the way you want by configuring the server with MariaDB's option files. The default MariaDB option file is called my.cnf on Unix-like operating systems and my.ini on Windows. Depending on how you've installed MariaDB, the default option file may be in a number of places, or it may not exist at all.
- How to optimize Mysql or MariaDB - Best VPS Guide 2021
- 10 MySQL settings to tune after installation - How to... blog
- Explains some of the InnoDB options and other options in a easy to read format.
- debian - What is the configuration file of MariaDB? - Stack Overflow
- Configuring MariaDB for Optimal Performance - MariaDB Knowledge Base
- Get the MariaDB variables
- MariaDB default my.cnf in sources - Stack Overflow
- No, MariaDB does not have a configuration file which would list all available options and their default values. Different MariaDB packages might provide some configuration files, but those are different, they only contain a small subset of options, and the values are different from default ones.
- You can output the default MariaDB variables and settings by running:
Default configuration and explanation of the settings mysqld --no-defaults --verbose --help or, on a running 10.1+ server, by executing SELECT variable_name, default_value FROM information_schema.system_variables ORDER BY variable_name
- You can output the current MariabDB variables:
- In the CWP GUI (SQL Services --> MySQL Manager --> Settings --> Show MySQL Variables) This runs mysql -e "show variables;" -B
- From the command line run one of these:
mysqld --verbose --help mysqladmin variables
- SHOW VARIABLES - MariaDB Knowledge Base
- MySQL Tutorial => SHOW VARIABLES example | RIP Tutorial
- MariaDB default my.cnf in sources - Stack Overflow
- MySQL Tuner
- GitHub - major/MySQLTuner-perl: MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability.
- MySQLTuner is a script written in Perl that allows you to review a MySQL installation quickly and make adjustments to increase performance and stability. The current configuration variables and status data is retrieved and presented in a brief format along with some basic performance suggestions.
- Releem - Automatic MySQL performance tuning. Boost MySQL performance in under a minute. - YouTube - This is a script that utilises the MySQL Tuner
- How to Optimize MySQL Performance Using MySQLTuner | Linode
- GitHub - major/MySQLTuner-perl: MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability.
- Example my.cnf files
- Optimized my.cnf configuration for MySQL/MariaDB (on Ubuntu, CentOS, Almalinux etc. servers) · GitHub - A complex example by Fotis who I think develops Joomla K2.
- Default my.cnf for MariaDB 10.3.12 · GitHub
- etc-server/mysql/my.cnf — Generic Config - Example MariaDB config file for medium systems.
- MySQL and MariaDB Configuration File template (my.cnf/my.ini) | FromDual
- The following MySQL configuration file is in our opinion a good average configuration file for MySQL, Galera Cluster, MariaDB and Percona Server. For MySQL servers more performance tuning is not need in most cases.
- MariaDB configuration file example | IBM - The following example of the my.cnf file contains the minimum resource configuration that was tested for runtime metrics collection.
- Optimized my.cnf configuration for MySQL 8 (on cPanel/WHM servers) • Best SEO Blog | HostSEO.com
- InnoDB to MyISAM in CWP - Knowledgebase - Host IT Smart - A very basic my.cnf file.
- my.cnf Configuration In Centos 7 | Webnoid Schools
my.cnf / my.ini Example with Annotations
This is an example my.cnf/my.ini (my-innodb-heavy-4G.ini) taken from an old version of Xampp running on Windows. This is useful because it has annotations against a lot of the settings.
#BEGIN CONFIG INFO #DESCR: 4GB RAM, InnoDB only, ACID, few connections, heavy queries #TYPE: SYSTEM #END CONFIG INFO # # This is a MySQL example config file for systems with 4GB of memory # running mostly MySQL using InnoDB only tables and performing complex # queries with few connections. # # MySQL programs look for option files in a set of # locations which depend on the deployment platform. # You can copy this option file to one of those # locations. For information about these locations, see: # http://dev.mysql.com/doc/mysql/en/option-files.html # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. # # More detailed information about the individual options can also be # found in the manual. # # # The following options will be read by MySQL client applications. # Note that only client applications shipped by MySQL are guaranteed # to read this section. If you want your own MySQL client program to # honor these values, you need to specify it as an option during the # MySQL client library initialization. # [client] #password = [your_password] port = 3306 socket = /tmp/mysql.sock # *** Application-specific options follow here *** # # The MySQL server # [mysqld] # generic configuration options port = 3306 socket = /tmp/mysql.sock # back_log is the number of connections the operating system can keep in # the listen queue, before the MySQL connection manager thread has # processed them. If you have a very high connection rate and experience # "connection refused" errors, you might need to increase this value. # Check your OS documentation for the maximum value of this parameter. # Attempting to set back_log higher than your operating system limit # will have no effect. back_log = 50 # Don't listen on a TCP/IP port at all. This can be a security # enhancement, if all processes that need to connect to mysqld run # on the same host. All interaction with mysqld must be made via Unix # sockets or named pipes. # Note that using this option without enabling named pipes on Windows # (via the "enable-named-pipe" option) will render mysqld useless! #skip-networking # The maximum amount of concurrent sessions the MySQL server will # allow. One of these connections will be reserved for a user with # SUPER privileges to allow the administrator to login even if the # connection limit has been reached. max_connections = 100 # Maximum amount of errors allowed per host. If this limit is reached, # the host will be blocked from connecting to the MySQL server until # "FLUSH HOSTS" has been run or the server was restarted. Invalid # passwords and other errors during the connect phase result in # increasing this value. See the "Aborted_connects" status variable for # global counter. max_connect_errors = 10 # The number of open tables for all threads. Increasing this value # increases the number of file descriptors that mysqld requires. # Therefore you have to make sure to set the amount of open files # allowed to at least 4096 in the variable "open-files-limit" in # section [mysqld_safe] table_open_cache = 2048 # Enable external file level locking. Enabled file locking will have a # negative impact on performance, so only use it in case you have # multiple database instances running on the same files (note some # restrictions still apply!) or if you use other software relying on # locking MyISAM tables on file level. #external-locking # The maximum size of a query packet the server can handle as well as # maximum query size server can process (Important when working with # large BLOBs). enlarged dynamically, for each connection. max_allowed_packet = 16M # The size of the cache to hold the SQL statements for the binary log # during a transaction. If you often use big, multi-statement # transactions you can increase this value to get more performance. All # statements from transactions are buffered in the binary log cache and # are being written to the binary log at once after the COMMIT. If the # transaction is larger than this value, temporary file on disk is used # instead. This buffer is allocated per connection on first update # statement in transaction binlog_cache_size = 1M # Maximum allowed size for a single HEAP (in memory) table. This option # is a protection against the accidential creation of a very large HEAP # table which could otherwise use up all memory resources. max_heap_table_size = 64M # Size of the buffer used for doing full table scans. # Allocated per thread, if a full scan is needed. read_buffer_size = 2M # When reading rows in sorted order after a sort, the rows are read # through this buffer to avoid disk seeks. You can improve ORDER BY # performance a lot, if set this to a high value. # Allocated per thread, when needed. read_rnd_buffer_size = 16M # Sort buffer is used to perform sorts for some ORDER BY and GROUP BY # queries. If sorted data does not fit into the sort buffer, a disk # based merge sort is used instead - See the "Sort_merge_passes" # status variable. Allocated per thread if sort is needed. sort_buffer_size = 8M # This buffer is used for the optimization of full JOINs (JOINs without # indexes). Such JOINs are very bad for performance in most cases # anyway, but setting this variable to a large value reduces the # performance impact. See the "Select_full_join" status variable for a # count of full JOINs. Allocated per thread if full join is found join_buffer_size = 8M # How many threads we should keep in a cache for reuse. When a client # disconnects, the client's threads are put in the cache if there aren't # more than thread_cache_size threads from before. This greatly reduces # the amount of thread creations needed if you have a lot of new # connections. (Normally this doesn't give a notable performance # improvement if you have a good thread implementation.) thread_cache_size = 8 # This permits the application to give the threads system a hint for the # desired number of threads that should be run at the same time. This # value only makes sense on systems that support the thread_concurrency() # function call (Sun Solaris, for example). # You should try [number of CPUs]*(2..4) for thread_concurrency thread_concurrency = 8 # Query cache is used to cache SELECT results and later return them # without actual executing the same query once again. Having the query # cache enabled may result in significant speed improvements, if your # have a lot of identical queries and rarely changing tables. See the # "Qcache_lowmem_prunes" status variable to check if the current value # is high enough for your load. # Note: In case your tables change very often or if your queries are # textually different every time, the query cache may result in a # slowdown instead of a performance improvement. query_cache_size = 64M # Only cache result sets that are smaller than this limit. This is to # protect the query cache of a very large result set overwriting all # other query results. query_cache_limit = 2M # Minimum word length to be indexed by the full text search index. # You might wish to decrease it if you need to search for shorter words. # Note that you need to rebuild your FULLTEXT index, after you have # modified this value. ft_min_word_len = 4 # If your system supports the memlock() function call, you might want to # enable this option while running MySQL to keep it locked in memory and # to avoid potential swapping out in case of high memory pressure. Good # for performance. #memlock # Table type which is used by default when creating new tables, if not # specified differently during the CREATE TABLE statement. default-storage-engine = MYISAM # Thread stack size to use. This amount of memory is always reserved at # connection time. MySQL itself usually needs no more than 64K of # memory, while if you use your own stack hungry UDF functions or your # OS requires more stack for some operations, you might need to set this # to a higher value. thread_stack = 192K # Set the default transaction isolation level. Levels available are: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE transaction_isolation = REPEATABLE-READ # Maximum size for internal (in-memory) temporary tables. If a table # grows larger than this value, it is automatically converted to disk # based table This limitation is for a single table. There can be many # of them. tmp_table_size = 64M # Enable binary logging. This is required for acting as a MASTER in a # replication configuration. You also need the binary log if you need # the ability to do point in time recovery from your latest backup. log-bin=mysql-bin # binary logging format - mixed recommended binlog_format=mixed # If you're using replication with chained slaves (A->B->C), you need to # enable this option on server B. It enables logging of updates done by # the slave thread into the slave's binary log. #log_slave_updates # Enable the full query log. Every query (even ones with incorrect # syntax) that the server receives will be logged. This is useful for # debugging, it is usually disabled in production use. #log # Print warnings to the error log file. If you have any problem with # MySQL you should enable logging of warnings and examine the error log # for possible explanations. #log_warnings # Log slow queries. Slow queries are queries which take more than the # amount of time defined in "long_query_time" or which do not use # indexes well, if log_short_format is not enabled. It is normally good idea # to have this turned on if you frequently add new queries to the # system. slow_query_log # All queries taking more than this amount of time (in seconds) will be # trated as slow. Do not use "1" as a value here, as this will result in # even very fast queries being logged from time to time (as MySQL # currently measures time with second accuracy only). long_query_time = 2 # *** Replication related settings # Unique server identification number between 1 and 2^32-1. This value # is required for both master and slave hosts. It defaults to 1 if # "master-host" is not set, but will MySQL will not function as a master # if it is omitted. server-id = 1 # Replication Slave (comment out master section to use this) # # To configure this host as a replication slave, you can choose between # two methods : # # 1) Use the CHANGE MASTER TO command (fully described in our manual) - # the syntax is: # # CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>, # MASTER_USER=<user>, MASTER_PASSWORD=<password> ; # # where you replace <host>, <user>, <password> by quoted strings and # <port> by the master's port number (3306 by default). # # Example: # # CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306, # MASTER_USER='joe', MASTER_PASSWORD='secret'; # # OR # # 2) Set the variables below. However, in case you choose this method, then # start replication for the first time (even unsuccessfully, for example # if you mistyped the password in master-password and the slave fails to # connect), the slave will create a master.info file, and any later # changes in this file to the variable values below will be ignored and # overridden by the content of the master.info file, unless you shutdown # the slave server, delete master.info and restart the slaver server. # For that reason, you may want to leave the lines below untouched # (commented) and instead use CHANGE MASTER TO (see above) # # required unique id between 2 and 2^32 - 1 # (and different from the master) # defaults to 2 if master-host is set # but will not function as a slave if omitted #server-id = 2 # # The replication master for this slave - required #master-host = <hostname> # # The username the slave will use for authentication when connecting # to the master - required #master-user = <username> # # The password the slave will authenticate with when connecting to # the master - required #master-password = <password> # # The port the master is listening on. # optional - defaults to 3306 #master-port = <port> # Make the slave read-only. Only users with the SUPER privilege and the # replication slave thread will be able to modify data on it. You can # use this to ensure that no applications will accidently modify data on # the slave instead of the master #read_only #*** MyISAM Specific options # Size of the Key Buffer, used to cache index blocks for MyISAM tables. # Do not set it larger than 30% of your available memory, as some memory # is also required by the OS to cache rows. Even if you're not using # MyISAM tables, you should still set it to 8-64M as it will also be # used for internal temporary disk tables. key_buffer_size = 32M # MyISAM uses special tree-like cache to make bulk inserts (that is, # INSERT ... SELECT, INSERT ... VALUES (...), (...), ..., and LOAD DATA # INFILE) faster. This variable limits the size of the cache tree in # bytes per thread. Setting it to 0 will disable this optimisation. Do # not set it larger than "key_buffer_size" for optimal performance. # This buffer is allocated when a bulk insert is detected. bulk_insert_buffer_size = 64M # This buffer is allocated when MySQL needs to rebuild the index in # REPAIR, OPTIMIZE, ALTER table statements as well as in LOAD DATA INFILE # into an empty table. It is allocated per thread so be careful with # large settings. myisam_sort_buffer_size = 128M # The maximum size of the temporary file MySQL is allowed to use while # recreating the index (during REPAIR, ALTER TABLE or LOAD DATA INFILE. # If the file-size would be bigger than this, the index will be created # through the key cache (which is slower). myisam_max_sort_file_size = 10G # If a table has more than one index, MyISAM can use more than one # thread to repair them by sorting in parallel. This makes sense if you # have multiple CPUs and plenty of memory. myisam_repair_threads = 1 # Automatically check and repair not properly closed MyISAM tables. myisam_recover # *** INNODB Specific options *** # Use this option if you have a MySQL server with InnoDB support enabled # but you do not plan to use it. This will save memory and disk space # and speed up some things. #skip-innodb # Additional memory pool that is used by InnoDB to store metadata # information. If InnoDB requires more memory for this purpose it will # start to allocate it from the OS. As this is fast enough on most # recent operating systems, you normally do not need to change this # value. SHOW INNODB STATUS will display the current amount used. innodb_additional_mem_pool_size = 16M # InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and # row data. The bigger you set this the less disk I/O is needed to # access data in tables. On a dedicated database server you may set this # parameter up to 80% of the machine physical memory size. Do not set it # too large, though, because competition of the physical memory may # cause paging in the operating system. Note that on 32bit systems you # might be limited to 2-3.5G of user level memory per process, so do not # set it too high. innodb_buffer_pool_size = 2G # InnoDB stores data in one or more data files forming the tablespace. # If you have a single logical drive for your data, a single # autoextending file would be good enough. In other cases, a single file # per device is often a good choice. You can configure InnoDB to use raw # disk partitions as well - please refer to the manual for more info # about this. innodb_data_file_path = ibdata1:10M:autoextend # Set this option if you would like the InnoDB tablespace files to be # stored in another location. By default this is the MySQL datadir. #innodb_data_home_dir = <directory> # Number of IO threads to use for async IO operations. This value is # hardcoded to 8 on Unix, but on Windows disk I/O may benefit from a # larger number. innodb_write_io_threads = 8 innodb_read_io_threads = 8 # If you run into InnoDB tablespace corruption, setting this to a nonzero # value will likely help you to dump your tables. Start from value 1 and # increase it until you're able to dump the table successfully. #innodb_force_recovery=1 # Number of threads allowed inside the InnoDB kernel. The optimal value # depends highly on the application, hardware as well as the OS # scheduler properties. A too high value may lead to thread thrashing. innodb_thread_concurrency = 16 # If set to 1, InnoDB will flush (fsync) the transaction logs to the # disk at each commit, which offers full ACID behavior. If you are # willing to compromise this safety, and you are running small # transactions, you may set this to 0 or 2 to reduce disk I/O to the # logs. Value 0 means that the log is only written to the log file and # the log file flushed to disk approximately once per second. Value 2 # means the log is written to the log file at each commit, but the log # file is only flushed to disk approximately once per second. innodb_flush_log_at_trx_commit = 1 # Speed up InnoDB shutdown. This will disable InnoDB to do a full purge # and insert buffer merge on shutdown. It may increase shutdown time a # lot, but InnoDB will have to do it on the next startup instead. #innodb_fast_shutdown # The size of the buffer InnoDB uses for buffering log data. As soon as # it is full, InnoDB will have to flush it to disk. As it is flushed # once per second anyway, it does not make sense to have it very large # (even with long transactions). innodb_log_buffer_size = 8M # Size of each log file in a log group. You should set the combined size # of log files to about 25%-100% of your buffer pool size to avoid # unneeded buffer pool flush activity on log file overwrite. However, # note that a larger logfile size will increase the time needed for the # recovery process. innodb_log_file_size = 256M # Total number of files in the log group. A value of 2-3 is usually good # enough. innodb_log_files_in_group = 3 # Location of the InnoDB log files. Default is the MySQL datadir. You # may wish to point it to a dedicated hard drive or a RAID1 volume for # improved performance #innodb_log_group_home_dir # Maximum allowed percentage of dirty pages in the InnoDB buffer pool. # If it is reached, InnoDB will start flushing them out agressively to # not run out of clean pages at all. This is a soft limit, not # guaranteed to be held. innodb_max_dirty_pages_pct = 90 # The flush method InnoDB will use for Log. The tablespace always uses # doublewrite flush logic. The default value is "fdatasync", another # option is "O_DSYNC". #innodb_flush_method=O_DSYNC # How long an InnoDB transaction should wait for a lock to be granted # before being rolled back. InnoDB automatically detects transaction # deadlocks in its own lock table and rolls back the transaction. If you # use the LOCK TABLES command, or other transaction-safe storage engines # than InnoDB in the same transaction, then a deadlock may arise which # InnoDB cannot notice. In cases like this the timeout is useful to # resolve the situation. innodb_lock_wait_timeout = 120 [mysqldump] # Do not buffer the whole result set in memory before writing it to # file. Required for dumping very large tables quick max_allowed_packet = 16M [mysql] no-auto-rehash # Only allow UPDATEs and DELETEs that use keys. #safe-updates [myisamchk] key_buffer_size = 512M sort_buffer_size = 512M read_buffer = 8M write_buffer = 8M [mysqlhotcopy] interactive-timeout [mysqld_safe] # Increase the amount of open files allowed per process. Warning: Make # sure you have set the global system limit high enough! The high value # is required for a large number of opened tables open-files-limit = 8192