mysql資料庫開發的經驗教訓,資料庫開發遇到的問題

本文目錄一覽：

• 1、剛開始學mysql資料庫,不明白其中的客戶端和伺服器,這裡的伺服器是要通過網路連接到達還是在安裝了
• 2、求高手優化MySQL資料庫，資料庫反應太慢。
• 3、關於在mysql中建表的問題
• 4、《深入淺出MySQL資料庫開發優化與管理維護第3版》pdf下載在線閱讀全文，求百度網盤雲資源
• 5、北大青鳥設計培訓：Mysql資料庫的設計和優化？

剛開始學mysql資料庫,不明白其中的客戶端和伺服器,這裡的伺服器是要通過網路連接到達還是在安裝了

1。首先說明一下伺服器和客戶端的分別，伺服器是指安裝mysql的那台機器，而客戶端是遠程通過網路使用伺服器上的mysql，客戶端通過得知遠程伺服器的ip地址以及mysql的一些密碼信息等使用mysql資料庫

2。說明一下資料庫是一個什麼樣的存在，在你安裝某種資料庫的時候都會配置一些系統信息，然後設定某些和機器硬體，比如內存等連接的埠，這樣通過這些埠，就可以把你先存儲的信息存到存儲空間去，而建立資料庫就是通過某些代碼（mysql）定義好的方式來建立某些存儲數據的空間。這樣每個資料庫其實就是一個存儲數據的存儲空間。

3.建立表的原理，其實就是在你已經建立好的資料庫庫存儲空間中，繼續分配空間給每一個表，然後每一個表裡再存儲數據

4.而上面你說的打幾句代碼建表，其實就是通過代碼，然後翻譯成機器語言，讓計算機分配出一些存儲空間，然後通過某些形式編譯成表的視圖樣式反應給你看，其實還是一個空間而已，這麼說明白了嗎？？

打了挺多，明白了得話給個採納，謝了

求高手優化MySQL資料庫，資料庫反應太慢。

在開始演示之前，我們先介紹下兩個概念。

概念一，數據的可選擇性基數，也就是常說的cardinality值。

查詢優化器在生成各種執行計劃之前，得先從統計信息中取得相關數據，這樣才能估算每步操作所涉及到的記錄數，而這個相關數據就是cardinality。簡單來說，就是每個值在每個欄位中的唯一值分布狀態。

比如表t1有100行記錄，其中一列為f1。f1中唯一值的個數可以是100個，也可以是1個，當然也可以是1到100之間的任何一個數字。這裡唯一值越的多少，就是這個列的可選擇基數。

那看到這裡我們就明白了，為什麼要在基數高的欄位上建立索引，而基數低的的欄位建立索引反而沒有全表掃描來的快。當然這個只是一方面，至於更深入的探討就不在我這篇探討的範圍了。

概念二，關於HINT的使用。

這裡我來說下HINT是什麼，在什麼時候用。

HINT簡單來說就是在某些特定的場景下人工協助MySQL優化器的工作，使她生成最優的執行計劃。一般來說，優化器的執行計劃都是最優化的，不過在某些特定場景下，執行計劃可能不是最優化。

比如：表t1經過大量的頻繁更新操作，（UPDATE,DELETE,INSERT），cardinality已經很不準確了，這時候剛好執行了一條SQL，那麼有可能這條SQL的執行計劃就不是最優的。為什麼說有可能呢？

來看下具體演示

譬如，以下兩條SQL，

A：

select * from t1 where f1 = 20;

B：

select * from t1 where f1 = 30;

如果f1的值剛好頻繁更新的值為30，並且沒有達到MySQL自動更新cardinality值的臨界值或者說用戶設置了手動更新又或者用戶減少了sample page等等，那麼對這兩條語句來說，可能不準確的就是B了。

這裡順帶說下，MySQL提供了自動更新和手動更新表cardinality值的方法，因篇幅有限，需要的可以查閱手冊。

那回到正題上，MySQL 8.0 帶來了幾個HINT，我今天就舉個index_merge的例子。

示例表結構：

mysql desc t1;+————+————–+——+—–+———+—————-+| Field      | Type         | Null | Key | Default | Extra          |+————+————–+——+—–+———+—————-+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+————+————–+——+—–+———+—————-+7 rows in set (0.00 sec)

表記錄數：

mysql select count(*) from t1;+———-+| count(*) |+———-+|    32768 |+———-+1 row in set (0.01 sec)

這裡我們兩條經典的SQL：

SQL C：

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select * from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1實際上在rank1,rank2,rank3三列上分別有一個二級索引。

那我們來看SQL C的查詢計劃。

顯然，沒有用到任何索引，掃描的行數為32034，cost為3243.65。

mysql explain  format=json select * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  “query_block”: {    “select_id”: 1,    “cost_info”: {      “query_cost”: “3243.65”    },    “table”: {      “table_name”: “t1”,      “access_type”: “ALL”,      “possible_keys”: [        “idx_rank1”,        “idx_rank2”,        “idx_rank3”      ],      “rows_examined_per_scan”: 32034,      “rows_produced_per_join”: 115,      “filtered”: “0.36”,      “cost_info”: {        “read_cost”: “3232.07”,        “eval_cost”: “11.58”,        “prefix_cost”: “3243.65”,        “data_read_per_join”: “49K”      },      “used_columns”: [        “id”,        “rank1”,        “rank2”,        “log_time”,        “prefix_uid”,        “desc1”,        “rank3”      ],      “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))”    }  }}1 row in set, 1 warning (0.00 sec)

我們加上hint給相同的查詢，再次看看查詢計劃。

這個時候用到了index_merge,union了三個列。掃描的行數為1103，cost為441.09，明顯比之前的快了好幾倍。

mysql explain  format=json select /*+ index_merge(t1) */ * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  “query_block”: {    “select_id”: 1,    “cost_info”: {      “query_cost”: “441.09”    },    “table”: {      “table_name”: “t1”,      “access_type”: “index_merge”,      “possible_keys”: [        “idx_rank1”,        “idx_rank2”,        “idx_rank3”      ],      “key”: “union(idx_rank1,idx_rank2,idx_rank3)”,      “key_length”: “5,5,5”,      “rows_examined_per_scan”: 1103,      “rows_produced_per_join”: 1103,      “filtered”: “100.00”,      “cost_info”: {        “read_cost”: “330.79”,        “eval_cost”: “110.30”,        “prefix_cost”: “441.09”,        “data_read_per_join”: “473K”      },      “used_columns”: [        “id”,        “rank1”,        “rank2”,        “log_time”,        “prefix_uid”,        “desc1”,        “rank3”      ],      “attached_condition”: “((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))”    }  }}1 row in set, 1 warning (0.00 sec)

我們再看下SQL D的計劃：

不加HINT，

mysql explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  “query_block”: {    “select_id”: 1,    “cost_info”: {      “query_cost”: “534.34”    },    “table”: {      “table_name”: “t1”,      “access_type”: “ref”,      “possible_keys”: [        “idx_rank1”,        “idx_rank2”,        “idx_rank3”      ],      “key”: “idx_rank1”,      “used_key_parts”: [        “rank1”      ],      “key_length”: “5”,      “ref”: [        “const”      ],      “rows_examined_per_scan”: 555,      “rows_produced_per_join”: 0,      “filtered”: “0.07”,      “cost_info”: {        “read_cost”: “478.84”,        “eval_cost”: “0.04”,        “prefix_cost”: “534.34”,        “data_read_per_join”: “176”      },      “used_columns”: [        “id”,        “rank1”,        “rank2”,        “log_time”,        “prefix_uid”,        “desc1”,        “rank3”      ],      “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))”    }  }}1 row in set, 1 warning (0.00 sec)

加了HINT，

mysql explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  “query_block”: {    “select_id”: 1,    “cost_info”: {      “query_cost”: “5.23”    },    “table”: {      “table_name”: “t1”,      “access_type”: “index_merge”,      “possible_keys”: [        “idx_rank1”,        “idx_rank2”,        “idx_rank3”      ],      “key”: “intersect(idx_rank1,idx_rank2,idx_rank3)”,      “key_length”: “5,5,5”,      “rows_examined_per_scan”: 1,      “rows_produced_per_join”: 1,      “filtered”: “100.00”,      “cost_info”: {        “read_cost”: “5.13”,        “eval_cost”: “0.10”,        “prefix_cost”: “5.23”,        “data_read_per_join”: “440”      },      “used_columns”: [        “id”,        “rank1”,        “rank2”,        “log_time”,        “prefix_uid”,        “desc1”,        “rank3”      ],      “attached_condition”: “((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))”    }  }}1 row in set, 1 warning (0.00 sec)

對比下以上兩個，加了HINT的比不加HINT的cost小了100倍。

總結下，就是說表的cardinality值影響這張的查詢計劃，如果這個值沒有正常更新的話，就需要手工加HINT了。相信MySQL未來的版本會帶來更多的HINT。

關於在mysql中建表的問題

建議第一種方案.

第二種方案盡量避免.

(1)數據條數比較多對mysql來說,根本不是問題.我的項目中資料庫紀錄條數過億.

(2)聯合主鍵很好,檢索到時會非常方便.你既然擔心紀錄條數多,那說明兩表關係聯動密切.以後的檢索極有可能要按b表的ID來統計之類.

(3)不光是檢索,維護使用A方案也非常方便.這方面我有教訓.

當a與b的表關係發生變化的時候.update逗號分隔的數據就要求變得非常小心.

比如去掉1,2,3之間的那個2,你就得把整個字元串取出來,replace掉那個2,

如果數據多的話,replace動作就要非常非常小心.

(4)如果採用第二方案,展現的時候也需要額外的split動作.雖然這個動作不複雜.但每次split很是讓人煩.

《深入淺出MySQL資料庫開發優化與管理維護第3版》pdf下載在線閱讀全文，求百度網盤雲資源

《深入淺出MySQL資料庫開發優化與管理維護第3版》百度網盤pdf最新全集下載:

鏈接：

?pwd=grx5 提取碼：grx5

簡介：《深入淺出MySQL：資料庫開發、優化與管理維護（第3版）》源自網易公司多位資深資料庫專家數年的經驗總結和MySQL資料庫的使用心得，在之前版本的基礎之上，基於MySQL 5.7版本進行了內容升級，同時也對MySQL 8.0的重要功能進行了介紹。除了對原有內容的更新之外，本書還新增了作者在高可用架構、資料庫自動化運維，以及資料庫中間件方面的實踐和積累。

《深入淺出MySQL：資料庫開發、優化與管理維護（第3版）》分為「基礎篇」「開發篇」「優化篇」「管理維護篇」和「架構篇」5個部分，共32章。基礎篇面向MySQL的初學者，介紹了MySQL的安裝與配置、SQL基礎、MySQL支持的數據類型、MySQL中的運算符、常用函數等內容。開發篇面向的是MySQL設計和開發人員，內容涵蓋了表類型（存儲引擎）的選擇、選擇合適的數據類型、字符集、索引的設計和使用、開發常用資料庫對象、事務控制和鎖定語句、SQL中的安全問題、SQL Mode及相關問題、MySQL分區等。優化篇針對的是開發人員和資料庫管理人員，內容包括SQL優化、鎖問題、優化MySQL Server、磁碟I/O問題、應用優化、PS/SYS資料庫、故障診斷等內容。管理維護篇適合資料庫管理員閱讀，介紹了MySQL高級安裝和升級、MySQL中的常用工具、MySQL日誌、備份與恢復、MySQL許可權與安全、MySQL監控、MySQL常見問題和應用技巧、自動化運維繫統的開發等內容。架構篇主要面向高級資料庫管理人員和資料庫架構設計師，內容包括MySQL複製、高可用架構、MySQL中間件等內容。

北大青鳥設計培訓：Mysql資料庫的設計和優化？

在JAVA開發中資料庫的學習也是我們需要了解的，截下來幾篇文章都是關於資料庫的設計和應用，那麼java課程培訓機構廢話不多說開始學習吧！  資料庫的設計  資料庫設計是基礎，資料庫優化是建立在設計基礎之上的。

好的資料庫一定擁有好的設計。

  資料庫設計的目標是為用戶和各種應用系統提供一個信息基礎設施和高效的運行環境。

  資料庫的三大範式  第一範式1NF:所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。

  第二範式2Nf:第二範式在第一範式的基礎之上更進一層。

第二範式需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。

也就是說在一個資料庫表中，一個表中只能保存一種數據，不可以把多種數據保存在同一張資料庫表中。

  第三範式3Nf:所有欄位必須與主鍵直接相關，而不是間接相關。

也可以理解為欄位不要和其他非主鍵欄位相關.  注意:這三個範式儘可能去遵守,不是一定要墨守成規.這只是讓我們設計的表的時候,越靠近這些範式,可以使欄位盡量的減小冗餘.但是有時候也可以根據實際需要小小的違背一下.但是第三範式違反一下還可以接受,但是第一範式別違反.  資料庫設計的步驟  需求分析階段  準確了解與分析用戶需求(包括數據與處理)。

是整個設計過程的基礎，是最困難、最耗費時間的一步。

  概念結構設計階段  是整個資料庫設計的關鍵–設計資料庫的E-R模型圖，確認需求信息的正確和完整  Entity_Relationship—實體之間的關係  一對一  一對多  多對一