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