MySQL

mysql_fetch_* 列函數mysql_fetch_* 列函數的主要功能是從查詢返回的結果集中取得相關的查詢結果，主要包括： mysql_fetch_array()：從結果集中取得一行作為關聯陣列或索引數組，或二者兼有 mysql_fetch_row()：從結果集中取得一行作為枚舉數組 mysql_fetch_assoc()：從結果集中取得一行作為關聯陣列 mysql_fetch_object()：從結果集中取得一行作為對象

按官方手冊推薦Innodb buffer Hit Ratios的計算是: 100-((iReads / iReadRequests)*100)iReads : mysql->status->Innodb_buffer_pool_readsiReadRequests: mysql->status->Innodb_buffer_pool_read_requests出處:

簡介：mysqlbinlog flashback功能是淘寶彭立勳(http://www.penglixun.com/)的一個很強勁的作品．主要功能：　對rows格式的binlog可以進行逆向操作．delete反向產生insert, update產生反向的update,insert反向產生delete．讓dba同學們也有機會簡單的恢複資料．可恢複:insert, update,delete相關的操作．示範一下使用過程：產生帶有flashback mysqlbinlog 工具：項止首頁：http:/

如下表：CREATE TABLE `t1` (`userid` int(11) DEFAULT NULL,`atime` datetime DEFAULT NULL,KEY `idx_userid` (`userid`)) ENGINE=InnoDB DEFAULT CHARSET=utf8； CREATE TABLE `t1` (`userid` int(11) DEFAULT NULL,`atime` datetime DEFAULT NULL,KEY `idx_userid`

在MySQL複製環境中，我們通常只根據 Seconds_Behind_Master 的值來判斷SLAVE的延遲。這麼做大部分情況下尚可接受，但並不夠準確，而應該考慮更多因素。首先，我們先看下SLAVE的狀態：複製代碼 代碼如下:yejr@imysql.com [(none)]> show slave status\G*************************** 1. row ***************************Slave_IO_State: Waiting

本次，我們來看看索引、提交頻率對InnoDB表寫入速度的影響，瞭解有哪些需要注意的。先直接說幾個結論吧：1、關於索引對寫入速度的影響：a、如果有自增列做主鍵，相對完全沒索引的情況，寫入速度約提升 3.11%；b、如果有自增列做主鍵，並且二級索引，相對完全沒索引的情況，寫入速度約降低

最近開發項目中又重新拿起了Mysql,在搭建環境的時候遇到了中文亂碼問題。下面我把我的解決方式跟大家分享一下 1、通過show VARIABLES like 'character_%'; 顯示出來所有的設定項目。把其中的非UTF8的編碼都設定成utf8 設定方式如 ： set character_set_server=utf8; 2、去mysql 安裝目錄下找到my.ini檔案。設定裡面的latin1為utf8

串連：mysql -h主機地址 -u使用者名稱 －p使用者密碼 （注:u與root可以不用加空格，其它也一樣）斷開：exit （斷行符號）建立授權：grant select on 資料庫.* to 使用者名稱@登入主機 identified by \"密碼\"修改密碼：mysqladmin -u使用者名稱 -p舊密碼 password 新密碼刪除授權: revoke select,insert,update,delete om *.*

表資料匯出到一個文字檔最簡單的方法是使用SELECT... INTO OUTFILE語句的查詢結果直接匯出到一個檔案在伺服器主機上。匯出資料的SELECT...INTO OUTFILE聲明：這句話的文法結合了常規的SELECT INTO OUTFILE檔案名稱的末尾。預設的輸出格式是相同的LOAD DATA，所以下面的語句匯出tutorials_tbl的表定位字元分隔的，換行結尾的檔案到/tmp/tutorials.txt：mysql> SELECT * FROM

相信大多數人都遇到過多執行個體安裝mysql吧，相信大多數人只要找到一份多執行個體安裝的教程就會很容易搞定了，但是越是順利的安裝過程越讓我們不安，為什麼呢，當我們在按照教程一步一步來的時候，你知道每句話的意思的目的嗎？出現錯誤以後的我們又該怎麼辦呢？現在我為大家展示我的安裝過程，各種糾結，各種錯誤。首先說明一個情境：我的電腦是ubuntu系統，之前apt-get自動安裝過mysql。這也是出現錯誤最多的原因之一。下面是我的安裝過程，其中充斥著各種錯誤：複製代碼 代碼如下:6.mkdir

想必大家在命令列操作mysql的時候會十分發愁現在的操作的是那個資料庫吧，至少我就糾結過，可能您會說我打一條命令不就知道了，是的這樣做確實可以的。可是今兒給大家介紹個好用的命令--prompt複製代碼 代碼如下:[root@fsailing1 ~]# mysql -uroot -p --prompt="\\u@\\h:\\d \\r:\\m:\\s>"Enter password:Welcome to the MySQL monitor.  Commands end with ;

前段時間，一大早上，就收到警示，警告php-fpm進程的數量超過閾值。最終發現是一條sql沒用到索引，導致執行資料庫查詢慢了，最終導致php-fpm進程數增加。最終通過analyze table feed_comment_info_id_0000 命令更新了Cardinality ，才能再次用到索引。排查過程如下：sql語句：select id from feed_comment_info_id_0000 where obj_id=101 and type=1;索引資訊：show index

我們在工作中時常會遇到一些客戶的TPS\QPS都不太高,但磁碟佔用非常大,一旦單一實例空間太大，像記憶體、網路、CPU以及備份都將增加相應的開銷。可能僅僅是由於空間不滿足使得我們不得不進行擴容，下面的方法提供給大家參考。有則改之無則加勉。1、表結構設計上1) 字元集是否遵循了最小化原則?(能用latin的就不用gbk。能用gbk的就不用utf8)2) 索引上是否有濫用？(根本不使用的欄位建索引、不適合建索引的欄位建索引、重複建索引或者不能很好的利用首碼索引等)3)

當用到socket來進行網路程式開發時，大多數情況下會遇到中文字元的發送與接收，這時若對發送的字串用預設的方式進行處理，則一般會得到一堆亂碼。由於中文字元採用雙位元組表示，所以對含有中文的字串的處理一定要按UNICODE編碼方式進行處理，也就是說，使用socket發送中文字串時要事先將字串轉成UNICODE格式的。下面是簡單的socket通訊的代碼。//服務端代碼 try{ IPAddress MyIP = IPAddress.Parse(“127.0.0.1″); TcpListener

一直以來，筆者都在不停尋找一種更人性化的資料庫訪問方式（並不是說預設的方式不好，而是有時候的確在模組化設計中不太方便）。後來有幸在php中找到codeigniter的ActiveReord，詳細參考這篇文章:

1.建立列    alter table tablename add colname type not null default '0′;    例： alter table mmanapp_mmanmedia add appid_id integer not null default 372;2.刪除列 alter table tablename drop column

mysql的字元集設定有多個層級，在mysql中儲存中文，如果不能正確設定字元集，很容易出現資料亂碼。今天就有一個使用者反饋他資料庫中的資料下午1點多開始出現了亂碼。在這裡，我分享下具體問題的排查過程，以及解決的辦法。（1）  排除用戶端設定導致的顯示亂碼如果使用者佈建的mysql character_set_client跟用戶端顯示的字元集不一致，很容易導致中文資料亂碼。設定session字元集為utf8：set names

mysql資料庫在做查詢時候，有時候是英文字母大小寫敏感的，有時候又不是的，主要是由mysql的字元校正規則的設定決定的，通常預設是不支援的大小寫字母敏感的。 1. 什麼是字元集和校正規則？字元集是一套符號和編碼。校對規則是在字元集內用於比較字元的一套規則。任何一個給定的字元集至少有一個校對規則，它可能有幾個校對規則。要想列出一個字元集的校對規則，使用SHOW COLLATION語句。校對規則一般有這些特徵：    兩個不同的字元集不能有相同的校對規則。&

問題使用者工單疑問：相同的語句，只是最後的limit行數不同。奇怪的是，limit 10 的效能比limit 100的語句還慢約10倍。隱藏使用者表資訊，語句及結果如下SELECT f1 , SUM(`f2`) `CNT` FROM T WHERE f1 IS NOT NULL AND f3 = '2014-05-12' GROUP BY f1 ORDER BY `CNT` DESC LIMIT 10;執行時間3 min 3.65 secSELECT f1 , SUM(`f2`) `CNT`

問題描述一個使用者反映先線一個SQL語句執行時間慢得無法接受。SQL語句看上去很簡單（本文描述中修改了表名和欄位名):SELECT count(*) FROM a JOIN b ON a.`S` = b.`S` WHERE a.`L` > '2014-03-30 00:55:00' AND a.`L` < '2014-03-30 01:00:00' ;且查詢需要的欄位都建了索引，表結構如下：CREATE TABLE `a` (`L` timestamp NOT NULL