MYSQL使用的時候遇到的一些問題

1.  以前使用的時候遇到編碼有問題。在MYSQL的命令行裏輸入了status結果顯示以下：

    Server characterset: latin1

    Db     characterset: utf8

    Client characterset: latin1

    Conn.  characterset: latin1

   解決： 命令行裏收入set names utf8結果顯示以下：

    Server characterset: latin1

    Db     characterset: utf8

    Client characterset: utf8

    Conn.  characterset: utf8

    參考： http://hi.baidu.com/leejun_2005/blog/item/99c471a69761148bd0435836.html

2. 依然是苦逼的編碼.今天往一個表插入數據,結果總是亂碼,剛開始覺得是表的編碼問題, 後來發現改了表的編碼之後依然有這樣的問題,以後才發現原來表的字段是有編碼的。我好土= =！

    參考： http://paulfzm.iteye.com/blog/761546

3. 事務/鎖= =！一直沒仔細去看過（但願之後開發能用上，嘿嘿）

     參考： http://hi.baidu.com/cubeking/item/1c1791adca371fa028ce9d18

                http://andyhu1007.iteye.com/blog/236271

                http://lectery.iteye.com/blog/357306

                http://blog.csdn.net/wangzhuoyan/article/details/4201485

                http://www.ningoo.net/html/2008/mysql_innodb_transaction_isolation_level.html

                http://space.itpub.net/8562502/viewspace-232238

                http://www.oschina.net/question/12_2760 （看的不是很懂)

    PS： MYSQL的InnoDB引擎下，可重複讀(Repeatable Read)的事務隔離級別不會形成「幻讀」。（在5.5.28版本下作的測試）,具體見官方文檔 http://dev.mysql.com/doc/refman/5.5/en/innodb-record-level-locks.html

By default, InnoDB operates in REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows (see Section 14.3.9.5, 「Avoiding the Phantom Problem Using Next-Key Locking」).