問答專欄Q & A COLUMN
1. 避免使用 select * 你需要什么信息,就查詢什么信息,查詢的多了,查詢的速度肯定就會慢
2. 當(dāng)你只需要查詢出一條數(shù)據(jù)的時候,要使用 limit 1 比如你要查詢數(shù)據(jù)中是否有男生,只要查詢一條含有男生的記錄就行了,后面不需要再查了,使用Limit 1 可以在找到一條數(shù)據(jù)后停止搜索
3. 建立高性能的索引 索引不是隨便加的也不是索引越多越好,更不是所有索引對查詢都有效
4. 建數(shù)據(jù)庫表時,給字段設(shè)置固定合適的大小. 字段不能設(shè)置的太大,設(shè)置太大就造成浪費,會使查詢速度變慢
5. 要盡量使用not null
6. EXPLAIN 你的 SELECT 查詢 使用EXPLAIN,可以幫助你更了解MySQL是如何處理你的sql語句的, 你可以查看到sql的執(zhí)行計劃,這樣你就能更好的去了解你的sql語句的不足,然后優(yōu)化語句.
7. 在Join表的時候,被用來Join的字段，應(yīng)該是相同的類型的,且字段應(yīng)該是被建過索引的,這樣，MySQL內(nèi)部會啟動為你優(yōu)化Join的SQL語句的機制。
8. 如果你有一個字段，比如“性別”，“國家”，“民族”, “省份”，“狀態(tài)”或“部門”，這些字段的取值是有限而且固定的，那么，應(yīng)該使用 ENUM 而不是 VARCHAR。
因為在MySQL中，ENUM類型被當(dāng)作數(shù)值型數(shù)據(jù)來處理，而數(shù)值型數(shù)據(jù)被處理起來的速度要比文本類型快得多。這樣，我們又可以提高數(shù)據(jù)庫的性能。
9. 垂直分割 將常用和有關(guān)系的字段放在相同的表中，把一張表的數(shù)據(jù)分成幾張表 這樣可以降低表的復(fù)雜度和字段的數(shù)目，從而達(dá)到優(yōu)化的目的
10. 優(yōu)化where查詢
①. 避免在where子句中對字段進行表達(dá)式操作
比如： select 列 from 表 where age*2=36; 建議改成 select 列 from 表 where age=36/2;
②. 應(yīng)盡量避免在 where 子句中使用 !=或 操作符，否則將引擎放棄使用索引而進行全表掃描。
③. 應(yīng)盡量避免在 where 子句中對字段進行 null 值 判斷
④. 應(yīng)盡量避免在 where 子句中使用 or 來連接條件
11. 不建議使用%前綴模糊查詢,這種查詢會導(dǎo)致索引失效而進行全表掃描
例如LIKE “%name”或者LIKE “%name%這兩種都是不建議的.但是可以使用LIKE “name%”。
對于LIKE “%name%,可以使用全文索引的形式
12. 要慎用in和 not in
例如：select id from t where num in(1,2,3) 建議改成 select id from t where num between 1 and 3
對于連續(xù)的數(shù)值，能用 between 就不要用 in 了
13. 理解in和exists， not in和not exists的區(qū)別
很多時候用 exists 代替 in 是一個好的選擇：如查詢語句使用了not in那么內(nèi)外表都進行全表掃描，沒用到索引，而not exists子查詢依然能用到表上索引，所以無論哪個表大，用not exists都比not in要快。
select num from a where num in(select num from b)
建議改成: select num from a where exists(select 1 from b where num=a.num)
區(qū)分in和exists主要是造成了驅(qū)動順序的改變（這是性能變化的關(guān)鍵），如果是exists，那么以外層表為驅(qū)動表，先被訪問，如果是IN，那么先執(zhí)行子查詢。所以IN適合于外表大而內(nèi)表小的情況；EXISTS適合于外表小而內(nèi)表大的情況。
關(guān)于not in和not exists，推薦使用not exists，不僅僅是效率問題，not in可能存在邏輯問題
14. 理解select Count (*)和Select Count(1)以及Select Count(column)區(qū)別
一般情況下，Select Count (*)和Select Count(1)兩著返回結(jié)果是一樣的
假如表沒有主鍵(Primary key), 那么count(1)比count(*)快，
如果有主鍵的話，那主鍵作為count的條件時候count(主鍵)最快
如果你的表只有一個字段的話那count(*)就是最快的
count(*) 跟 count(1) 的結(jié)果一樣，都包括對NULL的統(tǒng)計，而count(column) 是不包括NULL的統(tǒng)計
技術(shù)交流請關(guān)注“大數(shù)據(jù)java架構(gòu)師”
評論0
加載中...
我認(rèn)為可以大致從一下幾個方面考慮：
1、表結(jié)構(gòu)優(yōu)化。
根據(jù)當(dāng)前和未來可能擴展的業(yè)務(wù)需求，合理設(shè)計表結(jié)構(gòu)，合理拆分或合并，減少數(shù)據(jù)冗余。
2、索引優(yōu)化。
根據(jù)數(shù)據(jù)庫各個表的查詢業(yè)務(wù)設(shè)計合理的查詢索引?？梢詤⒖?《數(shù)據(jù)庫索引設(shè)計與優(yōu)化》一書。優(yōu)化系統(tǒng)存在的慢查詢，分析原因，對癥下藥。
3、考慮讀寫讀寫分離，小型數(shù)據(jù)庫集群構(gòu)建。或者查分相關(guān)業(yè)務(wù)到其他數(shù)據(jù)庫，比如redis， ES等。
評論0
加載中...
你問的太籠統(tǒng)了，想優(yōu)化什么？是優(yōu)化效率嗎？這個需要認(rèn)真分析，到底是你程序邏輯需要優(yōu)化，還是數(shù)據(jù)庫設(shè)計。這些都會造成數(shù)據(jù)庫訪問變慢。
評論0
加載中...
MySQL作為輕量級的互聯(lián)網(wǎng)數(shù)據(jù)庫先進代表以后應(yīng)該往企業(yè)級應(yīng)用領(lǐng)域發(fā)展。如ORACLE和SQLSERVER數(shù)據(jù)庫系統(tǒng)那樣除了擁有自己強大的核心數(shù)據(jù)庫存儲技術(shù)之外，還應(yīng)該在索引，并發(fā)，安全和分布式領(lǐng)域拓展發(fā)展，能做成如ORACLE ERP企業(yè)級應(yīng)用需要的集成開發(fā)工具，能實現(xiàn)SQLSERVER數(shù)據(jù)庫的虛擬化系統(tǒng)需要，從而能更好地支持PHP，C＋＋，DELPHI和JAVA等開發(fā)語言的多種實際應(yīng)用。
評論0
加載中...
我們知道，MySQL 一直依賴對 count(*) 的執(zhí)行很頭疼。很早的時候，MyISAM 引擎自帶計數(shù)器，可以秒回；不過 InnoDB 就需要實時計算，所以很頭疼。以前有多方法可以變相解決此類問題，比如：1. 模擬 MyISAM 的計數(shù)器比如表 ytt1，要獲得總數(shù)，我們建立兩個觸發(fā)器分別對 insert/delete 來做記錄到表 ytt1_count，這樣只需要查詢表 ytt1_count 就能拿到總數(shù)。ytt1_count 這張表足夠小，可以長期固化到內(nèi)存里。不過缺點就是有多余的觸發(fā)器針對 ytt1 的每行操作，寫性能降低。這里需要權(quán)衡。
2. 用 MySQL 自帶的 sql_calc_found_rows 特性來隱式計算
依然是表 ytt1，不過每次查詢的時候用 sql_calc_found_rows 和 found_rows() 來獲取總數(shù)，比如：
評論0
加載中...
安裝的時候有設(shè)置模板，可以搜索知數(shù)堂，然后根據(jù)你服務(wù)器配置進行少量調(diào)整，主要還是頭發(fā)數(shù)/INNODB相關(guān)緩存設(shè)置，這是基本優(yōu)化；到了業(yè)務(wù)方面，就只能根據(jù)相關(guān)范式進行優(yōu)化了；另外linux的優(yōu)化也要做，只是這部分是通用的，不是只為mysql做優(yōu)化
評論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
