數(shù)據(jù)庫(kù)作為應(yīng)用開發(fā)中必不缺少的基礎(chǔ)設(shè)施，其性能直接影響應(yīng)用的整體運(yùn)行速度。MySQL是目前最廣泛使用的關(guān)系型數(shù)據(jù)庫(kù)之一，對(duì)于開發(fā)人員寫出性能良好的SQL是必備的基本技能之一。下面簡(jiǎn)單描述下編寫SQL的注意事項(xiàng)。
10余年的岳塘網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整岳塘建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“岳塘網(wǎng)站設(shè)計(jì)”,“岳塘網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
編寫高質(zhì)量的SQL需要從以下幾個(gè)方面注意，基本原則、表字段注意事項(xiàng)、索引使用注意事項(xiàng)、SQL注意事項(xiàng)。
基本原則
一、盡量不要在數(shù)據(jù)庫(kù)里做運(yùn)算。如果遇到運(yùn)算盡可能在應(yīng)用程序?qū)舆M(jìn)行計(jì)算。
二、控制數(shù)據(jù)庫(kù)表數(shù)量、控制單表數(shù)據(jù)量、控制表的字段數(shù)。建議單庫(kù)不要超過(guò)四百?gòu)埍?，建議單表字段不要超過(guò)五十個(gè)，建議單表的數(shù)據(jù)量不要超過(guò)一千萬(wàn)。
三、不要編寫大SQL、不要使用大事務(wù)。SQL盡量寫的簡(jiǎn)單點(diǎn)拒絕編寫大SQL，可以將大SQL拆分成多個(gè)小SQL，在應(yīng)用層聚合。大事務(wù)拆分成多個(gè)小事務(wù)，快速提交。
表字段注意事項(xiàng)
一、選擇合適數(shù)值字段類型。能用小字段類型的就用小字段類型，如tinyint就比int(1)在表示小數(shù)據(jù)時(shí)合適。
二、能用數(shù)字表示就不要用字符。如可以用無(wú)符號(hào)INT存儲(chǔ)IP而不是字符串表示。
三、避免使用NULL字段。原因NULL字段查詢優(yōu)化難，含NULL復(fù)合索引失效。
四、少用或拆分TEXT/BLOB字段。字段太大需要更多的空間，性能低下，如需使用拆分到單獨(dú)表。
五、不要在表字段中存儲(chǔ)圖片。
索引使用注意事項(xiàng)
一、合理添加索引。索引添加太多會(huì)影響更新速度。能夠使用復(fù)合索引的避免加多個(gè)單獨(dú)索引。
二、字符字段建立前綴索引。
三、不在索引列做運(yùn)算。索引列做運(yùn)算會(huì)導(dǎo)致索引失效。
四、盡量不使用外建。
SQL類注意事項(xiàng)
一、 SQL語(yǔ)句盡可能簡(jiǎn)單。大SQL拆分成多個(gè)小SQL。
二、事務(wù)編寫盡量短小。事務(wù)即開即用用完立即關(guān)閉。
三、盡量不要使用select *。只取需要的列。
四、改寫OR為IN或者改寫為UNION操作。OR在數(shù)據(jù)量大的時(shí)候性能低于IN。
五、避免NOT、!=、、NOT IN、NOT EXISTS、NOT LIKE等查詢。
六、避免%前綴模糊查詢。
七、能用UNION ALL不要用UNION。
八、GROUP BY中去除排序。自帶排序。
九、同類型的字段做比較。字符類和字符類比較，數(shù)值類和數(shù)值類比較，不要混在一起比較。
十、盡量單表查詢，盡量不要多表關(guān)聯(lián)查詢。多表關(guān)聯(lián)查詢可以拆分成單表查詢?cè)趹?yīng)用程序中聚合數(shù)據(jù)。
十一、復(fù)合索引的多列注意最左原則。
上述注意事項(xiàng)能避免很多性能低下的SQL，希望在開發(fā)過(guò)程中能引起注意。
1、先安裝必須的軟件包：jdk和ssh：檢查java -version ;ssh -version 2、Hadoop安裝包： 3、安裝和配置：解壓安裝包，然后進(jìn)入conf文件夾，修改配置文件： Hadoop-env.sh: export JAVA_HOME=“...
只修改 frm 文件
從上面的例子我們看到修改表的 frm 文件是很快的 但MySQL 有時(shí)候會(huì)在沒(méi)有必要的時(shí)候也重建表 如果愿意冒一些風(fēng)險(xiǎn) 可以讓MySQL 做一些其他類型的修改而不用重建表
我們下面要演示的技巧是不受官方支持的 也沒(méi)有文檔記錄 并且也可能不能正常工作 采用這些技術(shù)需要自己承擔(dān)風(fēng)險(xiǎn) 建議在執(zhí)行之前首先備份數(shù)據(jù)！
下面這些操作是有可能不需要重建表的
移除（不是增加）一個(gè)列的 AUTO_INCREMENT屬性
增加 移除 或更改ENUM和SET常量 如果移除的是已經(jīng)有行數(shù)據(jù)用到其值的常量 查詢將會(huì)返回一個(gè)空字串值
基本的技術(shù)是為想要的表結(jié)構(gòu)創(chuàng)建一個(gè)新的 frm 文件 然后用它替換掉已經(jīng)存在的那張表的 frm 文件 像下面這樣
創(chuàng)建一張有相同結(jié)構(gòu)的空表 并進(jìn)行所需要的修改（例如增加ENUM 常量）
執(zhí)行FLUSH TABLES WITH READ LOCK 這將會(huì)關(guān)閉所有正在使用的表 并且禁止任何表被打開
交換 frm 文件
執(zhí)行UNLOCK TABLES 來(lái)釋放第 步的讀鎖
下面以給sakila film 表的rating 列增加一個(gè)常量為例來(lái)說(shuō)明 當(dāng)前列看起來(lái)如下
返回目錄 高性能MySQL
編輯推薦
ASP NET MVC 框架揭秘
Oracle索引技術(shù)
ASP NET開發(fā)培訓(xùn)視頻教程
lishixinzhi/Article/program/MySQL/201311/29671
字符串類型（ ）
MySQL 支持多種字符串類型 每種類型還有很多變種 這些數(shù)據(jù)類型在 和 版本發(fā)生了很大的變化 使得情況更加復(fù)雜 從MySQL 開始 每個(gè)字符串列可以定義自己的字符集和排序規(guī)則 或者說(shuō)校對(duì)規(guī)則（collation）（更多關(guān)于這個(gè)主題的信息請(qǐng)參考第 章） 這些東西會(huì)很大程度上影響性能
VARCHAR 和CHAR 類型
VARCHAR 和CHAR 是兩種最主要的字符串類型 不幸的是 很難精確地解釋這些值是怎么存儲(chǔ)在磁盤和內(nèi)存中的 因?yàn)檫@跟存儲(chǔ)引擎的具體實(shí)現(xiàn)有關(guān) 下面的描述假設(shè)使用的存儲(chǔ)引擎是InnoDB 和/ 或者M(jìn)yISAM 如果使用的不是這兩種存儲(chǔ)引擎 請(qǐng)參考所使用的存儲(chǔ)引擎的文檔
先看看VARCHAR 和CHAR 值通常在磁盤上怎么存儲(chǔ) 請(qǐng)注意 存儲(chǔ)引擎存儲(chǔ)CHAR 或者VARCHAR 值的方式在內(nèi)存中和在磁盤上可能不一樣 所以MySQL 服務(wù)器從存儲(chǔ)引擎讀出的值可能需要轉(zhuǎn)換為另一種存儲(chǔ)格式 下面是關(guān)于兩種類型的一些比較
VARCHAR
VARCHAR 類型用于存儲(chǔ)可變長(zhǎng)字符串 是最常見(jiàn)的字符串?dāng)?shù)據(jù)類型 它比定長(zhǎng)類型更節(jié)省空間 因?yàn)樗鼉H使用必要的空間（例如 越短的字符串使用越少的空間） 有一種情況例外 如果MySQL 表使用ROW_FORMAT=FIXED 創(chuàng)建的話 每一行都會(huì)使用定長(zhǎng)存儲(chǔ) 這會(huì)很浪費(fèi)空間
VARCHAR 需要使用 或 個(gè)額外字節(jié)記錄字符串的長(zhǎng)度 如果列的最大長(zhǎng)度小于或等于 字節(jié) 則只使用 個(gè)字節(jié)表示 否則使用 個(gè)字節(jié) 假設(shè)采用latin 字符集 一個(gè)VARCHAR（ ） 的列需要 個(gè)字節(jié)的存儲(chǔ)空間 VARCHAR（ ） 的列則需要 個(gè)字節(jié) 因?yàn)樾枰?個(gè)字節(jié)存儲(chǔ)長(zhǎng)度信息
VARCHAR 節(jié)省了存儲(chǔ)空間 所以對(duì)性能也有幫助 但是 由于行是變長(zhǎng)的 在UPDATE 時(shí)可能使行變得比原來(lái)更長(zhǎng) 這就導(dǎo)致需要做額外的工作 如果一個(gè)行占用的空間增長(zhǎng) 并且在頁(yè)內(nèi)沒(méi)有更多的空間可以存儲(chǔ) 在這種情況下 不同的存儲(chǔ)引擎的處理方式是不一樣的 例如 MyISAM 會(huì)將行拆成不同的片段存儲(chǔ) InnoDB則需要分裂頁(yè)來(lái)使行可以放進(jìn)頁(yè)內(nèi) 其他一些存儲(chǔ)引擎也許從不在原數(shù)據(jù)位置更新數(shù)據(jù)
下面這些情況下使用VARCHAR 是合適的 字符串列的最大長(zhǎng)度比平均長(zhǎng)度大很多 列的更新很少 所以碎片不是問(wèn)題 使用了像UTF 這樣復(fù)雜的字符集 每個(gè)字符都使用不同的字節(jié)數(shù)進(jìn)行存儲(chǔ)
在 或者更高版本 MySQL 在存儲(chǔ)和檢索時(shí)會(huì)保留末尾空格 但在 或更老的版本 MySQL 會(huì)剔除末尾空格
InnoDB 則更靈活 它可以把過(guò)長(zhǎng)的VARCHAR 存儲(chǔ)為BLOB 我們稍后討論這個(gè)問(wèn)題
CHAR
CHAR 類型是定長(zhǎng)的 MySQL 總是根據(jù)定義的字符串長(zhǎng)度分配足夠的空間 當(dāng)存儲(chǔ)CHAR 值時(shí) MySQL 會(huì)刪除所有的末尾空格（在MySQL 和更老版本中VARCHAR也是這樣實(shí)現(xiàn)的 也就是說(shuō)這些版本中CHAR 和VARCHAR 在邏輯上是一樣的 區(qū)別只是在存儲(chǔ)格式上） CHAR 值會(huì)根據(jù)需要采用空格進(jìn)行填充以方便比較
CHAR 適合存儲(chǔ)很短的字符串 或者所有值都接近同一個(gè)長(zhǎng)度 例如 CHAR 非常適合存儲(chǔ)密碼的MD 值 因?yàn)檫@是一個(gè)定長(zhǎng)的值 對(duì)于經(jīng)常變更的數(shù)據(jù) CHAR 也比VARCHAR 更好 因?yàn)槎ㄩL(zhǎng)的CHAR 類型不容易產(chǎn)生碎片 對(duì)于非常短的列 CHAR 比VARCHAR 在存儲(chǔ)空間上也更有效率 例如用CHAR（ ） 來(lái)存儲(chǔ)只有Y 和N 的值 如果采用單字節(jié)字符集注 只需要一個(gè)字節(jié) 但是VARCHAR（ ） 卻需要兩個(gè)字節(jié) 因?yàn)檫€有一個(gè)記錄長(zhǎng)度的額外字節(jié)
CHAR 類型的這些行為可能有一點(diǎn)難以理解 下面通過(guò)一個(gè)具體的例子來(lái)說(shuō)明 首先 我們創(chuàng)建一張只有一個(gè)CHAR（ ） 字段的表并且往里面插入一些值
當(dāng)檢索這些值的時(shí)候 會(huì)發(fā)現(xiàn)string 末尾的空格被截?cái)嗔?/p>
如果用VARCHAR（ ） 字段存儲(chǔ)相同的值 可以得到如下結(jié)果
數(shù)據(jù)如何存儲(chǔ)取決于存儲(chǔ)引擎 并非所有的存儲(chǔ)引擎都會(huì)按照相同的方式處理定長(zhǎng)和變長(zhǎng)的字符串 Memory 引擎只支持定長(zhǎng)的行 即使有變長(zhǎng)字段也會(huì)根據(jù)最大長(zhǎng)度分配最大空間 不過(guò) 填充和截取空格的行為在不同存儲(chǔ)引擎都是一樣的 因?yàn)檫@是在MySQL 服務(wù)器層進(jìn)行處理的
返回目錄 高性能MySQL
編輯推薦
ASP NET MVC 框架揭秘
Oracle索引技術(shù)
ASP NET開發(fā)培訓(xùn)視頻教程
lishixinzhi/Article/program/MySQL/201311/29687
重慶分公司
重慶分公司
