備份和恢覆命令 備份庫 直接在cmd視窗中直接輸入，結束不需要輸入； mysqldump -h埠號 -u用戶名 -p密碼 資料庫名>備份地址 恢復庫 在cmd視窗中進行 1、連接資料庫 mysql -u用戶名 -p密碼 2、創建資料庫 create database 庫名 3、切換到可用資料庫 u ...
備份和恢覆命令
備份庫
直接在cmd視窗中直接輸入，結束不需要輸入；
mysqldump -h埠號 -u用戶名 -p密碼 資料庫名>備份地址
恢復庫
在cmd視窗中進行
1、連接資料庫
mysql -u用戶名 -p密碼
2、創建資料庫
create database 庫名
3、切換到可用資料庫
use 庫名
4、進行恢復
source 備份文件地址
授權：
新用戶信息增改
1.創建用戶:
# 指定ip：192.118.1.1的用戶登錄
create user '用戶名'@'192.118.1.1' identified by '密碼';
# 指定ip：192.118.1.開頭的用戶登錄
create user '用戶名'@'192.118.1.%' identified by '密碼';
# 指定任何ip的用戶登錄
create user '用戶名'@'%' identified by '密碼';
2.刪除用戶
drop user '用戶名'@'IP地址';
3.修改用戶
rename user '用戶名'@'IP地址' to '新用戶名'@'IP地址';
4.修改密碼
set password for '用戶名'@'IP地址'=Password('新密碼');
用戶許可權管理
#查看用戶許可權
show grants for '用戶名'@'IP地址'
1、授權
#授權用戶僅對某文件有查詢、插入和更新的操作
grant select,insert,update on 文件名 to '用戶名'@'IP地址';
#授權所有的許可權，除了grant這個命令，這個命令是root才有的。用戶對db1下的t1文件有任意操作
grant all privileges on db1.t1 to '用戶名'@'IP地址';
#授權用戶可以對db1資料庫中的所有文件執行任何操作
grant all privileges on db1.* to '用戶名'@'IP地址';
#授權用戶可以對所有資料庫中文件有任何操作
grant all privileges on *.* to '用戶名'@'IP地址';
2、取消許可權
# 取消用戶對db1的t1文件的任意操作
revoke all on db1.t1 from '用戶名'@'IP地址';
# 取消來自遠程伺服器的mjj用戶對資料庫db1的所有表的所有許可權
revoke all on db1.* from '用戶名'@'IP地址';
# 取消來自遠程伺服器的mjj用戶所有資料庫的所有的表的許可權
revoke all privileges on *.* from '用戶名'@'IP地址';
為什麼使用視圖
多表的聯合查詢，最多也才3張表，如果面臨更多的表，為了簡化連表操作，可以使用MySQL中的視圖
好處
1、簡化sql語句
2、提高了sql的重用性
3、保護基表的數據，提高了安全性
創建視圖
create view 視圖名
as
查詢語句;
修改視圖
方式一
create or replace view 視圖名
as
查詢語句;
方式二
alter view 視圖名
as
查詢語句
刪除視圖
drop view 視圖1，視圖2,...;
查看視圖
desc 視圖名;
show create view 視圖名;
視圖和表的對比
| 關鍵字 | 是否占用物理空間 | 使用 | |
|---|---|---|---|
| 視圖 | view | 占用較小，只保存sql邏輯 | 一般用於查詢 |
| 表 | table | 保存實際的數據 | 增刪改查 |
什麼是索引
==索引用於快速找出在某個列中有一特定值的行，避免全表掃描==
MySQL索引，預設是B+樹索引
查詢表中的索引
show index from 表名
索引的優缺點
優點：
1、所有的MySQL列類型（欄位）都可以被索引，也就是可以給任意欄位設置索引
2、大大加快數據的查詢速度
缺點：
1、創建索引和維護索引要耗費時間，並且隨著數據量的增加所耗費的時間也會增加
2、索引也需要占空間，如果有大量的索引，索引文件可能會比數據文件更快達到上限值
3、當對錶中的數據進行增、刪、改時，索引也需要動態的維護，降低了數據的維護速度
索引的分類
單列索引（普通索引、唯一索引、主鍵索引）、組合索引、全文索引、空間索引
創建索引
普通索引(b+樹索引)
alter table table_name add index index_name(column_name) using btree;
create unique index index_name on table_name(column_name);
組合索引
唯一索引
全文索引
什麼是事務
事務是作為單個邏輯單元執行的一系列操作
多個操作作為一個整體向系統提交，要麼執行、要麼都不執行，事務是一個不可分割的工作工作邏輯單元
四大特性（ACID）
原子性（A -- Atomicity）：原子是參與化學反應中最小的粒子，不能再分割了，也就是說事務就是最小的，不能再分割了，如果把事務都分割了，就會出現問題
一致性（C -- Consistency）：在事務執行前資料庫的數據處於正確的狀態，而事務執行完成後資料庫的數據還是處於正確的狀態，即數據完整性約束沒有被破壞
隔離性（I -- Isolation）：事務與事務之間互不幹擾
持久性（D -- Durability）：通過事務進行操作後的數據，是永久保存的
註意：在實際開發中，經常會打破隔離性，當多個事務共同操作同一張表的時候，一旦打破了隔離性，就會出現安全問題
存儲引擎
存儲引擎：RDBMS中，決定了數據如何存儲，如何獲取，如何控制事務，如何控制外鍵等一系列功能的一套程式
**常用引擎：**InnoDB，MyIsam
InnoDB與MyIsam的區別
- InnoDB支持事務，支持外鍵；而MyIsam不支持事務，不支持外鍵
- InnoDB由於受到事務和外鍵的影響，所以對數據的存儲以及查詢效率偏低；MyIsam相反偏高
- InnoDB在存儲時，表文件是2個：frm，ibd；而MyIsam是3個文件，分別存儲frm，MYD，MYI
- InnoDB是MYSQL 5.5之後的預設存儲引擎；而MyIsam是5.5之前的預設存儲引擎
事務操作
方式一
開啟事務：start transaction;
提交事務：commit;
==註意==：當事務開啟之後，只有執行了commit，數據才會真的改變，如果沒有執行commit，數據還原
回滾事務：rollback;
方式二
修改預設的提交方式，預設是自動提交，我們要改成手動提交
show variables like '%autocommit%'
set @@autocommit=0（預設為1，自動提交；0，手動提交）
隔離級別
| 隔離級別 | 讀數據一致性及允許的併發副作用 | 備註 |
|---|---|---|
| 讀未提交（Read uncommitted） | 最低級別，只能保證不讀取物理上損壞的數據，事務可以看到其他事務沒有被提交的數據（臟數據） | |
| 讀已提交（Read commited） | 語句級，事務可以看到其他事務已經提交的數據 | Oracle資料庫預設 |
| 可重覆讀（Repeatable read） | 事務級，事務中兩次查詢的結果相同 | MySql資料庫預設 |
| 可串列讀（序列化Serializable） | 最高級別，事務級。順序執行 |
隔離等級越高，資料庫事務併發執行能力越差，能處理的操作越少。因此在實際項目開發中為了考慮併發性能一般使用讀已提交隔離級別，他能避免丟失更新和臟讀，儘管不可重覆讀和幻讀不能避免，但可以在可能出現的場合使用悲觀鎖或樂觀鎖來解決這些問題。
什麼是幻讀、不可重覆度、臟讀
1、臟讀：事務A讀取了事務B更新的數據，然後B回滾操作，那麼A讀取到的數據是臟數據，讀取到未提交的數據。
2、不可重覆讀：事務 A 多次讀取同一數據，事務 B 在事務A多次讀取的過程中，對數據作了更新並提交，導致事務A多次讀取同一數據時，結果不一致。
3、幻讀：系統管理員A將資料庫中所有學生的成績從具體分數改為ABCDE等級，但是系統管理員B就在這個時候插入了一條具體分數的記錄，當系統管理員A改結束後發現還有一條記錄沒有改過來，就好像發生了幻覺一樣，這就叫幻讀
隔離級別與更新丟失的情況
- 第一類更新丟失
- 事務A撤銷時，把已經提交的事務B的更新數據覆蓋了
- 第二類更新丟失
- 事務A覆蓋事務B已經提交的數據，造成事務B所做的操作丟失
| 隔離級別 | 臟讀 | 不可重覆讀 | 幻讀 | 第一類丟失更新 | 第二類丟失更新 |
|---|---|---|---|---|---|
| Read uncommitted | √ | √ | √ | × | √ |
| Read commited | × | √ | √ | × | √ |
| Repeatable read | × | × | √ | × | × |
| Serializable | × | × | × | × | × |
設置隔離級別
set session transaction isolation level 隔離級別
查看隔離級別(當前客戶端)
select @@tx_isolation
鎖
樂觀鎖
==預設存在==，什麼都不做，就是樂觀鎖。總是樂觀的認為，在維護這個數據的時候，沒有其他人來維護。
insert update delete 在執行SQL的同時，才給數據加上了樂觀鎖。
可能會導致的問題
age:12
A用戶:update table set age=32 where id=1
B用戶:update table set age=12 where id=1
A用戶:select * from table where id=1
這個時候，A用戶查看的數據為B修改過的，自己的修改已經被覆蓋
悲觀鎖
總是擔心，在自己修改數據的時候，有其他人，將這個數據修改，所以在修改數據之前，提前鎖住數據
==預設沒有開啟，需要自己開啟==
開啟命令
#在查詢語句後加for update就可以開啟（悲觀排他鎖）
select * from book for update
優缺點
優點：準確性高，更加安全
缺點：效率太低，一旦一個用戶執行悲觀鎖，那麼其他用戶都無法查看這個表的數據，也無法進行修改，除非執行悲觀鎖的用戶commit
行鎖
只會鎖住一行數據
select * from book where id=1 for update
表鎖
會鎖住整個的一個表
select * from book for update
排他鎖
A用戶在給表加排他鎖以後，那麼其他用戶都無法對錶進行操作、查看、加鎖
//表級排他鎖
lock table book write
//解鎖
unlock table
共用鎖
所有的用戶都可以對錶進行加鎖，但是，所有的用戶都無法對錶進行操作，包括上鎖的用戶
//表級共用鎖
lock table book read
//解鎖
unlock table
死鎖
兩個線程自己各自持有自己數據的鎖，但互相都想鎖住被對方鎖住的數據，就產生了死鎖
系統檢索到死鎖，會自動釋放一個鎖
