MySQL

 問題如下：編譯成功後，運行程式，出現./connect: error while loading shared libraries: libmysqlclient.so.15: cannot open shared object file: No such file or

對於大查詢有時需要‘分而治之’,將大查詢切分為小查詢: 每個查詢功能完全一樣，但只完成原來的一小部分，每次查詢只返回一小部分結果集。刪除舊的資料就是一個很好地例子。定期清理舊資料時，如果一條sql涉及了大量的資料時，可能會一次性鎖住多個表或行，耗費了大量的系統資源，卻阻塞了其他很多小的但重要的查詢。將一個大得DELETE語句切分為較小的查詢時，可以盡量減少影響msql的效能，同時減少mysql複製造成的延遲。例如，每個月會運行一次的語句，以清理三個月前的資料:mysql> DELETE

(1)關於設定檔路徑有時候，我發現雖然嘗試修改了設定檔的一些變數，但是並沒有生效。後來才發現原來是因為修改的檔案並非MySQL伺服器讀取的設定檔。如果不清楚MySQL當前使用的設定檔路徑，可以嘗試這樣查看:從可以看出, 伺服器首先會讀取/etc/my.cnf檔案，如果發現該檔案不存在，再依次嘗試從後面的幾個路徑進行讀取。(2)關於設定檔配置項分段設定檔my.cnf通常會分成好幾部分，如[client]，[mysqld],

按目前的情況，mysql是不支援跨伺服器間的資料拷貝的，也就是不能使用類似insert into db1.xx select * from db2.xx的語句。可以想到的主要有兩種方法：(1)先通過mysqdump將需要的資料導到sql檔案中，再通過mysql -uxxx -p -hxxx.xxx.x.xxx db2 <

很多時候，在mysql上實現的子查詢的效能較差，這聽起來實在有點難過。特別有時候，用到IN()子查詢語句時，對於上了某種數量級的表來說，耗時多的難以估計。本人mysql知識所涉不深，只能慢慢摸透箇中玄機了。假設有這樣的一個exists查詢語句：select * from table1where exists    (select * from table2 where id>=30000 and

(1)有一種情況下，order by可以在不滿足最左首碼規則時用到索引: 當前置列為常量時。例如有索引為  KEY my_idx (a,b,c)查詢語句為  select a,b,c from my_tbl where a=1 order by b,c。這樣由於索引第一列被指定為常數，即使order

(參考自<<高效能MySQL>>)假設有這樣的需求：寫一個UNION查詢，其第一個子查詢作為分支先執行，如果找到了匹配的行，則不再執行第二個分支的查詢。一般來說，我們可以寫出這樣的UNION查詢:select id from users where id=123456union allselect id from users_archived where id =

當一個表很大時，如果直接使用DELETE語句可能會花比較長的時間。在不確定要刪除的資料是否存在與表中時，可以先select一條記錄看看是否有資料返回，(如SELECT 1 FROM tbl WHERE dt BETWEEN '2013-05-01' AND '2013-07-01' LIMIT

Mysql日期使用總結 按月份統計當月記錄數select pid,DATE_FORMAT(adddate,'%Y-%c'),count(*) as abc from T_TONE_LOG group by pid,DATE_FORMAT(adddate,'%Y-%c')%Y 年 %c 月 連和查詢（找出 t1 在t2 中沒有的） select * from T_COMPANY_SINGER_SONG as t1 left join T_SONG_NEW as t2 on (t1.song_id 

mysql可以運行在不同sql mode模式下面，sql mode模式定義了mysql應該支援的sql文法，資料校正等！ 一、設定方法：［mysqld] －－下添加如下設定transaction-isolation=SERIALIZABLEsql-mode=ANSI二、模式說明：查看預設的sql mode模式： select

在mysql5.1以後的版本：http://mysql.isu.edu.tw/Downloads/MySQL-5.1/MySQL-client-community-5.1.29-0.rhel5.i386.rpm用戶端帶了個工具mysqlslap可以對mysql進行壓力測試：可以使用mysqlslap --help來顯示使用方法：Default options are read from the following files in the given

分別為192.168.0.11  主      192.168.0.12  從的兩台伺服器，主伺服器出了點問題，於是把從伺服器升為主，主修複後變為從了，在my.cnf中把192.168.0.12的master-host等選項禁掉，重啟後發現slave的狀態總是為原來的設定，而不是 Empty set用reset slave也是不行的。 可以用change master to master_host='';取消原slave的設定，執行後就可以使slave 狀態變成空了mysql> show

每一步、在mysql從伺服器的資料庫上建立使用者名稱和密碼，僅給replication client許可權。第二步，在被監控的Mysql從伺服器上建立指令碼Check-mysql-slave#!/bin/sh declare -a    slave_is slave_is=($(/usr/local/mysql/bin/mysql -unagios -p******    -e "show slave status\G"|grep Running |awk '{print $2}')) if [

#!/bin/bash#Shell variablesSHELLNAME="mysqlbak"SCRIPTDIR="/data/dbbackup/"BACKUPDIR="/data/dbbackup/"LOGFILE=$SCRIPTDIR"/"$SHELLNAME".log"#Date/Time veriablesREMAINDAYS="3"CDATE=$(date "+%Y-%m-%d")CTIME=$(date "+%H-%M-%S")#Rsync

第一步yum update wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/epel-release-5-4.noarch.rpm wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/ius-release-1.0-10.ius.el5.noarch.rpmrpm -Uvh epel-release-5-4.noarch.rpmrpm -Uvh

哈哈，為什麼我要笑呢？          因為我太無聊了。一到周末都不知道幹什麼呢？到論壇混了混，有個哥們出100分，求個圖片上傳到資料庫的例子。 網上應該不少，於是想了想要不這分還是我賺吧（- -！）。寫個吧，以後誰需要直接改改就成了。好了步入正題： 首先聲明下，我的本本沒有安裝別的資料庫，就個mysql（因為小麼- -！），其實都差不多。 資料庫的建立：資料庫名叫：csdn表名：savepictureDROP TABLE IF EXISTS `savepicture`;CREATE

這兩年都是用oracle，mysql雖然簡單不過一些常用語句記不住。當然也可以使用navicat工具。這裡做個小筆記。之後如果有用到一點一點的添加進來。show databases;use 資料庫名;show tables;主鍵：ALTER TABLE `testtable` ADD PRIMARY KEY (`id`);ALTER TABLE `testtable` DROP PRIMARY KEY;alert:ALTER TABLE `testtable` MODIFY COLUMN

 摘要：如果在比較小的列上設定索引的話，其索引所佔用的資源也會比較少。那麼資料庫管理員該如何給自己的資料減肥呢?對此筆者有如下幾個建議。　　在資料庫最佳化工作中，使資料儘可能的小，使表在硬碟上佔據的空間儘可能的小，這是最常用、也是最有效手段之一。因為縮小資料，相對來說可以提高硬碟的讀寫速度，並且在查詢過程中小表的內容處理時所佔用的系統資源比較少。同理，如果在比較小的列上設定索引的話，其索引所佔用的資源也會比較少。那麼資料庫管理員該如何給自己的資料減肥呢?對此筆者有如下幾個建議。

 Linux有很多很好的記憶體、IO調度機制，但是並不會適用於所有情境。對於DBA來說Linux比較讓人頭疼的一個地方是，它不會因為MySQL很重要就避免將分配給MySQL的地址空間映射到swap上。對於頻繁進行讀寫操作的系統而言，資料看似在記憶體而實際上在磁碟是非常糟糕的，回應時間的增長很可能直接拖垮整個系統。這篇blog主要講講我們作為DBA，怎樣盡量避免MySQL慘遭swap的毒手。首先我們要瞭解點基礎的東西，比如說為什麼會產生swap。假設我們的實體記憶體是16G，swap是4G。如果M

在應用系統開發初期，由於開發資料庫資料比較少，對於查詢SQL語句，複雜視圖的的編寫等體會不出SQL語句各種寫法的效能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中資料的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統最佳化中一個很重要的方面就是SQL語句的最佳化。對于海量資料，劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍，可見對於一個系統不是簡單地能實現其功能就可，而是要寫出高品質的SQL語句，提高系統的可用性。　　在多數情況下，Oracle使用索引來更快地