對於手握數據庫的開發人員來講,沒有誤刪過庫的人生是不完整的。不過刪庫之後不用急着跑,說不定能夠恢復呢?mysql
21分鐘MySQL基礎入門linux
我下面全部的SQL語句是基於MySQL 5.6+運行。nginx
- 開始使用
- 增刪改查
- WHERE
- AND 和 OR
- ORDER BY
- IN
- NOT
- UNION
- AS
- JOIN
- SQL 函數
- 觸發器
- 添加索引
- 建立後表的修改
從零開始學習MySQL,主要是面向MySQL數據庫管理系統初學者。
MySQL高性能學習筆記程序員
- 1、Ubuntu 安裝mysql
- 2、sysbench基準測試
- 3、服務器性能剖析
- 4、慢查詢
- 5、Alter Table操做性能提高
認識索引是什麼東西很是關鍵,一個很是恰當的比喻就是書的目錄頁與書的正文內容之間的關係,爲了方便查找書中的內容,經過對內容創建索引造成目錄。所以,首先你要明白的一點就是,索引它也是一個文件,它是要佔據物理空間的。
可能有時候咱們會問,「個人服務器有50 GB內存,12核CPU,怎樣配置最好?」 很遺憾,問題沒這麼簡單,MySQL 服務器的配置應該符合它的工做負載,數據,以及應用需求,並不只僅看硬件的狀況。一般只須要把基本的項配置正確,應該將更多的時間花費在 schema 的優化,索引,以及查詢設計上。
MySQL多列索引的應用shell
咱們常常聽到一些人說"把WHERE條件裏的列都加上索引",其實這個建議很是錯誤。在多個列上創建單獨的索引大部分狀況下並不能提升MySQL的查詢性能。MySQL在5.0以後引入了一種叫「索引合併」(index merge)的策略,必定程度上可使用表上的多個單列索引來定位指定的行。可是當服務器對多個索引作聯合操做時,一般須要耗費大量CPU和內存資源在算法的緩存、排序和合並操做上,特別是當其中有些索引的選擇性不高,須要合併掃描大量的數據的時候。這個時候,咱們須要一個多列索引。數據庫
MySql之主從複製segmentfault
mysql的主從複製不但能夠做爲數據庫備份,也能實現數據庫的讀寫分離,爲之後處理高併發打下基礎。
分佈式數據庫分爲主數據庫(master)和從數據庫(slaves)
主從複製的基本流程:
- 在master上更新的內容以二進制日誌(Binary Log)的方式存在本地
- slaves開啓IO線程拿到master服務器上的二進制流文件,並存入中繼日誌(Relay Log)。這個工做叫作:binlog dump process
- slaves再開啓一個SQL線程來讀取反序列化後的中繼日誌,執行其中的sql語句,達到備份數據庫的效果
最近開發中遇到的一個MySQL主從延遲的坑,記錄並總結,避免再次犯一樣的錯誤。
Ottter是由阿里巴巴開源的一個數據同步產品,它的最初的目的是爲了解決跨國異地機房雙A架構,兩邊可寫的場景,開發時間從2011年7月份一直持續到如今,目前阿里巴巴B2B內部的本地/異地機房的同步需求基本全上了Otter。Otter基於數據庫增量日誌解析,支持mysql/oracle數據庫進行同步,在最新的v4.2.13已經支持mysql5.7以及阿里雲提供的RDS數據庫(使用RDS童鞋的福音)。
在項目中使用mysql數據庫,全部的增刪改查操做都在主庫處理,隨着查詢訪問量的增長,單庫處理的壓力驟增,爲了防止主庫故障,使用一主多從的方式,經過讀寫分離,把全部的查詢處理都放到從服務器上,減小單點故障致使整個服務掛掉的狀況。
MySQL中字段類型與合理的選擇字段類型;int(11)最大長度是多少?,varchar最大長度是多少
MySQL 的數值數據類型能夠大體劃分爲兩個類別,一個是整數,另外一個是浮點數或小數。許多不一樣的子類型對這些類別中的每個都是可用的,每一個子類型支持不一樣大小的數據,而且 MySQL 容許咱們指定數值字段中的值是否有正負之分(UNSIGNED)或者用零填補(ZEROFILL)。
鎖是數據庫系統區別於文件系統的一個關鍵特性。鎖機制用於管理對共享資源的併發訪問,提供數據的完整性和一致性。
InnoDB存儲引擎不只會在行級別上對錶數據上鎖,還會在數據庫內部其餘多個地方使用鎖,從而容許對多種不一樣資源提供併發訪問。如:操做緩衝池中LRU列表,刪除、添加、移動LRU列表中的元素,爲了保證數據的完整性,必須有鎖的介入。
在工做中,咱們常常會遇到這樣的問題,須要更新庫存,當咱們查詢到可用的庫存準備修改時,這時,其餘的用戶可能已經對這個庫存數據進行修改了,致使,咱們查詢到的數據會有問題,下面咱們就來看解決方法。
nginx有很強大的日誌功能,可是在缺省狀態下,它只能記錄用戶的IP地址以及瀏覽器信息。若是咱們有用戶登陸註冊系統,在用戶已登陸的狀況下,想記錄訪問某一個網頁的究竟是哪個用戶,怎麼辦呢?由於咱們不僅想知道究竟是哪個IP地址訪問了哪個網頁,而且還想知道究竟是哪個登陸用戶訪問了哪個網頁,這對於咱們往後有針對性地向他/她推薦信息甚至推送廣告都是很是有用的。
mysql(InnoDB)事務隔離級別(READ UNCOMMITTED) 與 鎖
- 1、經過 show status 命令瞭解各類 sql 的執行頻率
- 2、定義執行效率較低的 sql 語句
- 3、經過 explain 分析低效 sql 的執行計劃
- 4、經過 performance_schema 分析 sql 性能
- 5、經過 trace 分析優化器如何選擇執行計劃。
- 6、 肯定問題並採起相應的優化措施
- 性能降低SQL慢的緣由
- 常見通用的join查詢
- 索引
- 索引的使用
聲明一下:下面的優化方案都是基於 「 Mysql-索引-BTree類型 」 的。
前幾天在作一個需求的時候,須要清理mysql中重複的記錄,當時的想法是經過代碼遍歷寫出來,而後以爲太複雜,內心想着應該能夠經過一個sql語句來解決問題的。查了資料,請教了大佬以後得出了一個很便利的sql語句,這裏分享下這段sql語句和思路。
咱們的Mysql服務運行一段時間後,不知什麼緣由就變慢了,怎麼查找緣由呢?
- 1、關鍵性指標
- 2、TPCC測試關鍵性指標
- 3、數據庫參數配置優化
- 4、MySQL系統狀態
對MySQL進行優化主要能夠從如下幾個方面進行:效果: SQL語句和索引 > 數據庫對象:表結構、字段類型、存儲引擎 > 配置 > 硬件
但成本從低到高。
MySQL 提供了一個 EXPLAIN 命令,它能夠對 SELECT 語句進行分析,並輸出 SELECT 執行的詳細信息,以供開發人員針對性優化。而EXPLAIN 命令用法十分簡單,在 SELECT 語句前加上 Explain 就能夠了。
MySQL的大多數事務型存儲引擎實現的其實都不是簡單的行級鎖。基於提高併發性能的考慮,它們通常都同時實現了多版本併發控制(MVCC)。不只是MySQL,包括Oracle,PostgreSQL等其餘數據庫系統也都實現了MVCC,但各自的實現機制不盡相同,由於MVCC沒有一個統一的實現標準。能夠認爲MVCC是行級鎖的一個變種,可是它在不少狀況下避免了加鎖操做,所以開銷更低。雖然實現機制有所不一樣,但大都實現了非阻塞的讀操做,寫操做也只鎖定必要的行。
事務 能夠理解爲一個獨立的工做單元,在這個獨立的工做單元中,有一組操做;放在事務(獨立工做單元)中的多個操做,要麼所有執行成功,要麼所有執行失敗。
當MySQL單表記錄數過大時,增刪改查性能都會急劇降低,能夠參考如下步驟來優化:
- 單表優化
- 讀寫分離
- 緩存
- 表分區
- 垂直拆分
- 水平拆分
- 兼容MySQL且可水平擴展的數據庫
- NoSQL
提及MySQL的查詢優化,相信你們收藏了一堆奇技淫巧:不能使用SELECT *、不使用NULL字段、合理建立索引、爲字段選擇合適的數據類型..... 你是否真的理解這些優化技巧?是否理解其背後的工做原理?在實際場景下性能真有提高嗎?我想未必。於是理解這些優化建議背後的原理就尤其重要,但願本文能讓你從新審視這些優化建議,並在實際業務場景下合理的運用。
單表60億記錄等大數據場景的MySQL優化和運維之道 | 高可用架構
MySQL數據庫你們應該都很熟悉,並且隨着前幾年的阿里的去IOE,MySQL逐漸引發更多人的重視。
MySQL的優勢:
- 使用簡單
- 開源免費
- 擴展性「好」,在必定階段擴展性好
- 社區活躍
- 性能能夠知足互聯網存儲和性能需求,離不開硬件支持
上面這幾個因素也是大多數公司選擇考慮MySQL的緣由。不過MySQL自己存在的問題和限制也不少,有些問題點也常常被其餘數據庫吐槽或鄙視。
肖鵬,微博研發中心技術經理,主要負責微博數據庫(MySQL/Reids/HBase/Memcached)相關的業務保障、性能優化、架構設計,以及周邊的自動化系統建設。經歷了微博數據庫各個階段的架構改造,包括服務保障及SLA體系建設、微博多機房部署、微博平臺化改造等項目。10年互聯網數據庫架構和管理經驗,專一於數據庫的高性能和高科用技術保障方向。
- 1、 備份恢復策略
- 2、 邏輯備份和恢復
- 3、物理備份和恢復
- 4、 表的導入導出
本身日常用的一個shell腳本,起自動備份mysql中全部數據庫做用,在任務執行完成後,會記錄日誌和自動發送郵件到郵箱。配合crontab能夠實現天天自動備份。
目標: 每隔1分鐘,導出.sql,壓縮,並按日期存儲在/data 下,每分鐘後刪除.sql文件,每隔2分鐘刪除.tar.gz文件知識: 定時任務 crontab , mysqldump 導出 , tar 打包壓縮, 按日期建立文件 date
這裏使用的是網易郵箱126郵箱的STMP服務,服務器是smtp.126.com。若是你使用其它第三方郵箱,在賬號設置那裏通常都有說明SMTP服務器地址。
對於備份的數據文件咱們可能會存放在服務器目錄,備份週期的話固然是按照數據量來講的,這裏咱們通常都是天天的凌晨備份一次。備份後的文件存放在咱們的服務器的目錄下面,可是萬一有一天服務器也崩潰了,那麼備份的文件也就沒了。
因此咱們設想一個好的方案就是數據庫天天備份,每次備份自動提交到遠程倉庫,這裏我以碼云爲例。
使用xtrabackup對MySQL innodb表熱備份,增量備份
對於數據庫的備份重要性沒必要多言,爲了防止數據以各類方式丟失,損壞,必須對數據庫進行按期備份。首先考慮備份的時候對數據庫業務的影響。
再者若是按期進行備份,若是每次都進行全量備份,顯然一部分數據是重複,浪費大量磁盤空間。
今天遇到一個很傻逼的問題,有人登上開發服務器,不知是有意仍是無意;把mysql裏面的庫所有刪除了。。。那我的結果如何,咱們就不做討論了。。。沒辦法我只能寫個shell腳本,用crontab跑下定時;作些簡單的數據備份了,順便寫個筆記。
其實很簡單:
- 寫一個shell腳本經過mysql的mysqldump,將數據導出成對應的sql文件;
- 使用linux的crontab定時運行對應腳本,將sql,文件保存到對應的目錄下;
- 可想而知,隨着數據量的增長和備份的頻率都會致使備份服務器的硬盤資源使用率也會直線攀升;爲了解決這個問題,咱們就須要,定時清理備分內容;而我仍是簡單的使用了個shell腳本,經過crontab定時去清理;
基本上每一個跟數據庫打交道的程序員(固然也多是你同事)都會碰一個問題,MySQL誤操做後如何快速回滾?好比,delete一張表,忘加限制條件,整張表都沒了。假如這仍是線上環境核心業務數據,那這事就鬧大了。誤操做後,能快速回滾數據是很是重要的。
本期完
:)
歡迎關注 SegmentFault 講堂服務號 :)