最近在幫人調優MYSQL時,感覺mysql的query cache其實並不是越大越好的,因為其實當資料表有如下變化時,CACHE實際時失效的:包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等所以如果表是頻繁讀的話,那對query cache調整下還可以,否則還是沒怎麼作用的.附調整參數:Query Cache相關參數:query_cache_size QC佔用空間大小,通過將其設定為0
mysql innodb中,還是存在當恢複recovery故障後,時間很長的問題,查了下,原來原因如下:當故障發生,重新啟服務後,會自動完成恢複操作,將資料庫恢複到之前一個正常狀態。恢複進程會完成兩步,第一步:檢查redo日誌,將之前完成並提交的事務全部重做;第二步:將undo日誌中,未完成提交的事務,全部取消。那麼,就僅僅做了這麼兩步為什麼恢複過程會變得如此漫長呢?在InnoDB未對恢複速度做提升之前,MySQL的bug列表中,曾被提出了兩個改進請求:Bug #29847和Bug #49535
在一些情況下,MySQL可以直接使用索引來滿足一個 ORDER BY 或 GROUP BY 子句而無需做額外的排序。儘管 ORDER BY 不是和索引的順序準確匹配,索引還是可以被用到,只要不用的索引部分和所有的額外的 ORDER BY 欄位在 Where 子句中都被包括了。下列的幾個查詢都會使用索引來解決 ORDER BY 或 GROUP BY 部分:Select * FROM t1 orDER BY key_part1,key_part2,... ;Select * FROM t1
Can't open file: '.\test\mytable.frm' (errno: 24)shell> perror 24OS error code 24: Too many open files 這樣的錯誤的話,應該是mysql的檔案描述符不夠了,解決的方法為,增加操作系統的描述符號:設定OS參數(如果你有許可權的話):在檔案/etc/security/limits.conf新增如下行:mysql soft nofile 65535mysql hard nofile 65535
前幾天, 在管理系統的時候遇到一個奇怪的問題, 今天才有機會安裝好MySQL環境來重現此問題,由於不是最原始的環境, 所以未必能夠完全重現, 我只能努力重現關鍵問題了.. 我覺得此問題有點特別, 故在此大概的回想下當時的情景..工作時, 執行了一個su – mysql 的命令, 遇到了下面這樣一個錯誤..view sourceprint?1 [root@dbmain ~]# su - mysql 2 su: cannot set user id: Resource temporarily
SHOW DATABASES //列出 MySQL Server 資料庫。SHOW TABLES [FROM db_name] //列出資料庫資料表。SHOW TABLE STATUS [FROM db_name] //列出資料表及表狀態資訊。SHOW COLUMNS FROM tbl_name [FROM db_name] //列出資料表欄位SHOW
記錄檔類型概述:1.錯誤記錄檔記錄啟動、運行或停止mysqld時出現的問題。My.ini配置資訊:#Enter a name for the error log file.Otherwise a default name will be used.#log-error=d:/mysql_log_err.txt2.查詢日誌記錄建立的用戶端串連和執行的語句。My.ini配置資訊:#Enter a name for the query log file. Otherwise a default
(呵)近一段時間由於工作需要,終於開始玩Linux了,今天搞了一天的MySQL編譯安裝,記錄下來,備忘吧!! (卡)安裝環境:VmWare5(橋接模式) + RedHat E AS 4 + 已安裝了開發工具以及相關開發包(安裝Linux系統時自己要定製的),並測試成功 (!)先給出MySQL For Linux 源碼,是xx.tar.zg格式的http://www.filewatcher.com/m/mysql-5.0.45.tar.gz.24433261.0.0.html (1)