= MySQL and the MySQLdb Python bindings for MySQL =

 ''work in progress, only the most critical information is there for now''

Starting with [milestone:0.10] Trac can use MySQL for its DatabaseBackend, but only starting with [milestone:0.10.4] will MySQL be fully supported (at least that's the plan). So stick to [milestone:0.10.3] for now.


== Requirements ==
=== MySQL ===

In order to avoid several issues with unicode and international characters throughout Trac (e.g., international characters turning into question marks with mysterious "Incorrect string value" errors logged), we '''''strongly''''' advise MySQL users to only use databases having the ''`utf8`'' character set and the ''`utf8_general_ci`'' collation type. However, changing collation to ''utf8'' makes MySQL fail in 4.1.x and 5.0.x versions on MyISAM table type, because some Trac tables indexes become "too big". This will be (hopefully) addressed in [milestone:0.10.4]. As a workaround it has been [comment:ticket:3659:5 recommended] to use InnoDB tables instead of MyISAM where this limitation is absent.

Such databases can be created with the MySQL monitor, like that:
{{{
CREATE DATABASE trac DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 
}}}

XXX: I think the above advice on collations is wrong - using a case-insensitive collation does not sound right, and when I used the above command, the indexing process failed when it came to insert a revision which included changes to files with names differing only in case. Recreating the db using the utf8_bin collation allowed things to work as expected.
 ''See also: [comment:ticket:4378:5 #4378], where someone stated the opposite (i.e. that setting the collation mode to utf8_bin was ''not'' enough... Maybe this depends on the type of tables used. Anyway, there's a patch on #4378 that should solve that issue in all cases.''

To check character set settings for your database, issue command:
{{{
mysql> USE trac;
Database changed
mysql> SHOW VARIABLES LIKE '%character%';
+--------------------------+--------------------
| Variable_name            | Value
+--------------------------+--------------------
| character_set_client     | cp1251
| character_set_connection | cp1251
| character_set_database   | utf8
| character_set_filesystem | binary
| character_set_results    | cp1251
| character_set_server     | utf8
| character_set_system     | utf8
| character_sets_dir       | C:\DevServer\Instal
+--------------------------+--------------------
8 rows in set (0.00 sec)
mysql>
}}}

See also #3884.

=== MySQLdb ===
The recommended version is MySQL-python 1.2.2.

See http://cheeseshop.python.org/pypi/MySQL-python/1.2.2, which contains links to the .tar.gz source distribution as well as pre-built Windows eggs.

Older versions can be found at the [https://sourceforge.net/projects/mysql-python/ mysql-python] sourceforge project:
 - MySQL-python 1.2.1_p2 was the previously recommended version
 - MySQL-python 1.2.0-3.2.2, MySQL-python 1.2.2b2) were reported to have issues (see #3645).  
 - MySQL-python-1.2.2b2 was [googlegroups:trac-users:e291b3ecb4a990a1 reported] to solve an `AttributeError: 'array.array' object has no attribute 'startswith'` error seen when viewing a changeset... These problems ought to be fixed in 1.2.2b3; if they are not, or if you have other issues, please file a bug in the [https://sourceforge.net/tracker/?group_id=22307&atid=374932 MySQL-python Bug Tracker].

== Known Issues ==
=== Still Opened ===
[[TicketQuery(keywords=~mysql&status=!closed&group=milestone)]]

=== Typical Problems ===
[[TicketQuery(keywords=~mysql&resolution=worksforme&group=milestone)]]

(corresponding [query:keywords=~mysql&status=!closed&group=milestone custom query])

== Conversion ==

While a more robust method may be created for [milestone:0.10.4] to allow easy conversion from SQLite to MySQL, users have reported success with the [wiki:SqLiteToMySql following method].