事務和鎖的關系？ 事務是由鎖來支持的 ## 事務的隔離級別 # read uncommitted 臟讀 兩個事務中，其中一個事務進行了add語句還沒有commit,另一個事務就可以讀取到，這是很危險的 # read committed 不可重復讀 沒有commit的是不能在另一個事務中讀取出來的 # repeatable read 可重復讀(默認) 一旦讀取出來就鎖定了，不影響其他事務的讀取 不管提不提交 都不會讀到不一樣的數據 ## 晃讀 但存在晃讀，可能沒查詢出來，但是可以更新，另一個事務commit之后就可以看見 ## 死鎖 同一個主鍵執行更新 相互在等待另外一把鎖 #serializable 序列化 不存在死鎖 一旦進行更新insert，那么另外的事務必須進行commit 否則會一直等待，會影響速度 for update是排他鎖 不允許同時讀select lock in share mode 允許其他事務讀 索引是用奧查樹存儲的 6 5 8 1 2 8 11 select * from quanzhan order by uid limit 199,10; 化在搜索索引的時間多 select * from quanzhan where uid>199 order by uid limit 0,10; # 為什么有數據庫 - 快速、永久、安全的存儲大量數據 - 關系型數據庫:結構化數據存儲 - 常用數據庫: - MySQL、PostgreSQL、Oracle、MS SQL SQLite、MongoDB # 關系型數據庫約束 三范式: 1. 每一列都是不可分割的原子數據項(基本類型列) 2. 要求實體的屬性完全依賴于主關鍵字(無重復行) 3. 數據表不包含其它表已有的非主屬性(無數據冗余) 非關系型數據庫特點,是不是也滿足三范式? 更多范式: BC范式:非鍵字段確定主鍵的一部分 用戶聯系方式表:uid courseid mobile 主鍵(uid,courseid)mobile(唯一) 4范式:多字段鍵且沒有非鍵字段,鍵的一部分確定另一部分的多個值 用戶技能表:uid departmentid skill 1 1 PHP 1 2 PHP 2 3 Swift # SQL操作 ### DDL(Data Definition Language)數據定義語言 create、alter、drop、truncate、comment、grant、revoke ### DML(Data Manipulation Language)數據操作語言 select、insert、update、delete、call、explain、lock table ### DCL(Data Control Language)數據控制語言 commit、savepoint、rollback、set transaction **truncate與delete區別** # MySQL插件 NoSql 插件 HandlerSocket 中文全文索引插件 mysqlcft 新存儲引擎XtraDB 可能成為InnoDB存儲引擎的替代 # MySQL分支 Percona:MySQL咨詢公司Percona發布。他們是XtraDB存儲 引擎的原作者。 MariaD:MySQL的初始創建者的團隊開發,提供MyISAM和 InnoDB以及XtraDB Drizzle:對MySQL進行一些重大更改 # 關系型數據庫安全 事務與并發 事務的ACID: 1. 原子性(Atomicity ) 全部執行或全部不執行 2.一致性( Consistency)事務前后數據都是一致性狀態,約束等 3.隔離性或獨立性( Isolation) 4.事務之間是獨立的,和級別相關 5. 持久性(Durabilily) 事務完成即持久化存儲 事務與鎖的關系? # 事務隔離級別 SQL的4種事務隔離模式: read uncommitted 臟讀 read committed 不可重復讀 repeatable read 可重復讀(默認) serializable 串行 # MySQL事務試驗 MySQL事務隔離模式: 查看: SELECT @@GLOBAL.tx_isolation, @@tx_isolation; 設置: set global transaction isolation level read uncommitted; 事務提交參數: set autocommit = 0; innodb_flush_log_at_trx_commit 0 每秒保存 1 每事務保存 2 操作系統決定 # MySQL鎖表類型 1. 表級鎖(MyISAM):開銷小,加鎖快;不會出現死鎖;鎖定粒 度大,發生鎖沖突的概率最高,并發度最低 show status like 'table%'; 2. 行級鎖(InnoDB):開銷大,加鎖慢;會出現死鎖;鎖定粒度最 小,發生鎖沖突的概率最低,并發度也最高 showstatuslike 'innodb_row_lock%'; 3. 頁面鎖:開銷和加鎖時間界于表鎖和行鎖之間;會出現死鎖;鎖定 粒度界于表鎖和行鎖之間,并發度一般 并發問題 任務: $numval = select num from table where id=1; update table set num=$numval+1 where id=1; # 悲觀鎖與樂觀鎖解決并發 ##悲觀鎖: 1)serializable; 2)select ... where id=1 for update; //不允許其他事務讀 ##樂觀鎖: repeatable read: select ... where id=1 lock in share mode; //允許其他事務讀 解決:update table set ...version=version+1 where ...version=@ver; 例:update table set num=num-1 where num>0; 鎖實驗: 1、lock in share mode 2、for update 從完整性考慮 a)外鍵、子查詢、聯合查詢 b)發帖子: begin; insert into tiezi(tid,uid,content) values(100,1,'xxx'); update user set tcount=tcount+1 where uid=1; commit; c)依賴事務,適合場景? #從高負載考慮 a)分庫分表 帖子可能在不同的表或數據庫里 b)發帖子: 帖子表插入正確 用戶表增加總數,不處理正確性 修正策略 c)用戶金錢? # 選擇何種多級分類方式 1 前端 2 后端多表 3 無限分類 數組展現、遞歸展現 分次展現 # 演示一個大數據量表的分頁 取數據按主鍵排序,不加其它條件。索引已經是最優。 來看看分頁效率如何 批量插入數據提示: max_allowed_packet #海量數據的分頁優化 1 建立合適的索引 2 緩存count,根據訪問熱度緩存靠后的分頁數據 MySQL查表行數方式 SQL_CALC_FOUND_ROWS select FOUND_ROWS() 3 數據表拆分(建索引表,按年歸檔等) 4 SQL轉換 5 產品設計優化