1. 資料庫id自動增長,數據不停的刪除和插入,這樣的話id欄位會不斷的變大,直到溢出這個問題是怎麼解決的
這個看情況了，首先看看是不是有使用自增列的必要，如果有必要前期要有預見性，對於可能會出現溢出的情況，則盡量使用bigint類型，當然這個要多佔用存儲空間。如果刪除操作比較規則，比如會定期刪除較早的數據，那麼可以在id即將溢出的時候重置種子，從頭開始自增，如果不能循環使用id值得話只能在即將溢出的時候修改表，用更大的數據類型來作為自增列的類型，這個過程因為涉及大量的數據更新插入操作，速度會很慢，通常盡量避免。如果id快溢出了，最好新建一個表來存儲新增的數據。
2. 企業數據運維場景復雜會帶來什麼風險呢
在安華金和公眾號文章里看到說在數據運維場景中，分兩個方向考慮，一個是數據運維場景復雜，一個是運維人員許可權寬泛。隨著企業發展，機房建設、人員波動、業務系統擴容會變得愈加頻繁，帶來了復雜的運維場景，例如公用資料庫賬號、公用運維主機、公用的操作系統賬號等；與此同時，數據的運維管理工作仍是傳統的「企業運維人員+一大堆第三方廠商人員」模式。面對如此復雜、混亂的運維場景，如果不具備有效的、細粒度的管控能力，那麼諸如數據被誤操作、惡意批量刪除、高許可權用戶的濫用、敏感數據的泄露等數據安全事件的發生，將難以避免，並對企業造成不可估量的經濟損失與聲譽損害。我知道安華金和有專門針對資料庫運維場景的管控產品，你去問問他們~
3. 超詳細Mysql資料庫優化
資料庫優化一方面是找出系統的瓶頸,提高MySQL資料庫的整體性能,而另一方面需要合理的結構設計和參數調整,以提高用戶的相應速度,同時還要盡可能的節約系統資源,以便讓系統提供更大的負荷.
1. 優化一覽圖
2. 優化
筆者將優化分為了兩大類,軟優化和硬優化,軟優化一般是操作資料庫即可,而硬優化則是操作伺服器硬體及參數設置.
2.1 軟優化
2.1.1 查詢語句優化
1.首先我們可以用EXPLAIN或DESCRIBE(簡寫:DESC)命令分析一條查詢語句的執行信息.
2.例:
顯示:
其中會顯示索引和查詢數據讀取數據條數等信息.
2.1.2 優化子查詢
在MySQL中,盡量使用JOIN來代替子查詢.因為子查詢需要嵌套查詢,嵌套查詢時會建立一張臨時表,臨時表的建立和刪除都會有較大的系統開銷,而連接查詢不會創建臨時表,因此效率比嵌套子查詢高.
2.1.3 使用索引
索引是提高資料庫查詢速度最重要的方法之一,關於索引可以參高筆者<MySQL資料庫索引>一文,介紹比較詳細,此處記錄使用索引的三大注意事項:
2.1.4 分解表
對於欄位較多的表,如果某些欄位使用頻率較低,此時應當,將其分離出來從而形成新的表,
2.1.5 中間表
對於將大量連接查詢的表可以創建中間表,從而減少在查詢時造成的連接耗時.
2.1.6 增加冗餘欄位
類似於創建中間表,增加冗餘也是為了減少連接查詢.
2.1.7 分析表,,檢查表,優化表
分析表主要是分析表中關鍵字的分布,檢查表主要是檢查表中是否存在錯誤,優化表主要是消除刪除或更新造成的表空間浪費.
1. 分析表: 使用 ANALYZE 關鍵字,如ANALYZE TABLE user;
2. 檢查表: 使用 CHECK關鍵字,如CHECK TABLE user [option]
option 只對MyISAM有效,共五個參數值:
3. 優化表:使用OPTIMIZE關鍵字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不寫入日誌.,優化表只對VARCHAR,BLOB和TEXT有效,通過OPTIMIZE TABLE語句可以消除文件碎片,在執行過程中會加上只讀鎖.
2.2 硬優化
2.2.1 硬體三件套
1.配置多核心和頻率高的cpu,多核心可以執行多個線程.
2.配置大內存,提高內存,即可提高緩存區容量,因此能減少磁碟I/O時間,從而提高響應速度.
3.配置高速磁碟或合理分布磁碟:高速磁碟提高I/O,分布磁碟能提高並行操作的能力.
2.2.2 優化資料庫參數
優化資料庫參數可以提高資源利用率,從而提高MySQL伺服器性能.MySQL服務的配置參數都在my.cnf或my.ini,下面列出性能影響較大的幾個參數.
2.2.3 分庫分表
因為資料庫壓力過大，首先一個問題就是高峰期系統性能可能會降低，因為資料庫負載過高對性能會有影響。另外一個，壓力過大把你的資料庫給搞掛了怎麼辦？所以此時你必須得對系統做分庫分表 + 讀寫分離，也就是把一個庫拆分為多個庫，部署在多個資料庫服務上，這時作為主庫承載寫入請求。然後每個主庫都掛載至少一個從庫，由從庫來承載讀請求。
2.2.4 緩存集群
如果用戶量越來越大，此時你可以不停的加機器，比如說系統層面不停加機器，就可以承載更高的並發請求。然後資料庫層面如果寫入並發越來越高，就擴容加資料庫伺服器，通過分庫分表是可以支持擴容機器的，如果資料庫層面的讀並發越來越高，就擴容加更多的從庫。但是這里有一個很大的問題：資料庫其實本身不是用來承載高並發請求的，所以通常來說，資料庫單機每秒承載的並發就在幾千的數量級，而且資料庫使用的機器都是比較高配置，比較昂貴的機器，成本很高。如果你就是簡單的不停的加機器，其實是不對的。所以在高並發架構里通常都有緩存這個環節，緩存系統的設計就是為了承載高並發而生。所以單機承載的並發量都在每秒幾萬，甚至每秒數十萬，對高並發的承載能力比資料庫系統要高出一到兩個數量級。所以你完全可以根據系統的業務特性，對那種寫少讀多的請求，引入緩存集群。具體來說，就是在寫資料庫的時候同時寫一份數據到緩存集群里，然後用緩存集群來承載大部分的讀請求。這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的並發。
一個完整而復雜的高並發系統架構中，一定會包含：各種復雜的自研基礎架構系統。各種精妙的架構設計.因此一篇小文頂多具有拋磚引玉的效果,但是資料庫優化的思想差不多就這些了.
4. 如何進行mysql的動態擴容和縮容
mysql在線擴容和縮容一般涉及到的內容，主要包括三個方面，1.在線也就意味著需要把增量的數據重新分布到新的拓撲結構中,我們一般稱做增量復制，2.原有的數據需要一條不漏的掃出來重新分布到新的拓撲結構中,這個一般叫做全量復制，3.全量做完，增量正在同步，把應用的數據路由拓撲切到新的路由拓撲上來，並且做到無數據丟失，這個我們叫做停寫切換。做好這三個方面的工作，能夠達到的效果就是應用在最後切換數據分布拓撲的時刻，只要停寫非常短的時間(秒級別)就能夠做到無數據丟失的擴容和縮容。
增量同步一般有2種方式，一種是應用端或者資料庫前端做trigger,記錄變更數據的特徵值log(比如pk,sharding key)，然後非同步復制到新的拓撲結構中。另外一種方式是通過分析mysql的binlog再進行不同數據拓撲的復制。兩者本質上來說應該是一樣的，後者可能更加簡便，並且對應用無侵入，前者雖然也能夠做到，實際實現或者推廣和操作上都有不少阻力，最起碼解析binlog方式是mysql一上去，更新的log已經天然存在與binlog中了。
增量同步的兩種方式如果要考慮到同步的可伸縮性(也就是多台機器可以同時消費相同的變更日誌)，需要在原數據中添加數據的版本信息防止更新亂序，或者通過唯一鍵進行復制機器的sharding,也就是不同進程(線程)同時消費相同的更新日誌，必須讓同一條記錄的更新落在同一個線程裡面，如果還需要保證復制的事務，那麼實現會非常復雜，一般不會去支持多線程下復制的事務。
全量復制，也就是掃描需要復制的表的數據進行重新分布，主要存在的問題是復制速度和對資料庫的寫入壓力的矛盾，其實能夠做到整個拓撲連資料庫都全部換掉，來達到對正在使用資料庫的0影響，這個是一種可行的方案，另外是分時段調整復制線程數，一般單線程復制對於資料庫的影響不會很大，在凌晨再轉換成多線程方式達到提速的目標。
擴容或者縮容在最後階段如何切換，這個涉及到的問題主要是如何避免新更新進來以至於增量沒完沒了，方式有很多，最簡單的方法就是停掉應用，一般時間只有幾分鍾是可以接受的。另外一種是邏輯停寫，因為我們遷移的時候是有一個規則去重新散列數據，也就是如果新的規則和舊的規則兩者算出來的結果不一致，那麼這個數據就是需要被遷移的，如果在停寫的時刻，向前端拋錯即可。邏輯停寫最大的好處就是避免PE的介入，並且配合動態的數據路由數據推送，可以完全避免重新發布達到擴容或者縮容，這個就是真正的在線擴容，停寫不可避免（等待延遲的增量同步完成），但是不影響讀。
數據擴容或者縮容，我們覺得不應該排入業務的開發日程中，而是由數據管理團隊對應用透明地進行這種操作，最後介入的人員只是DBA而已。但是不像一些nosql一樣按容量或者完全透明的split,資料庫的sharding還是按照應用的數據特性（pk,user_id,gmt_create等等不同欄位，自選策略）進行sharding,應用知道他們的某條數據具體存在哪個機器哪張表上，這個無論對於開發還是測試或者DBA都是一件不錯的事情。