【持續更新】node
一、mysql如何作分頁mysql
mysql數據庫作分頁用limit關鍵字,它後面跟兩個參數startIndex和pageSize面試
二、mysql引擎有哪些,各自的特色是什麼?redis
innodb和myisam兩個引擎,二者區別是
innodb支持事物,myisam不支持
innodb支持外鍵,myisam不支持
innodb不支持全文索引,myisam支持全文索引
innodb提供提交、回滾、崩潰恢復能力的事物的安全能力,實現併發控制
myisam提供較高的插入和查詢記錄的效率,主要用於插入和查詢算法
三、數據庫怎麼創建索引sql
create index account_index on `table name `(`字段名`(length)數據庫
四、一張表多個字段,怎麼建立組合索引django
create index account_index on `table name `(`字段名`,'字段名')編程
五、如何應對數據的高併發,大量的數據計算windows
1.建立索引
2.數據庫讀寫分離,兩個數據庫,一個做爲寫,一個做爲讀
3. 外鍵去掉
4.django中orm表性能相關的
select_related:一對多使用,查詢主動作連表
prefetch_related:多對多或者一對多的時候使用,不作連表,作屢次查詢
六、數據庫內連表、左連表、右連表
內鏈接是根據某個條件鏈接兩個表共有的數據
左鏈接是根據某個條件以及左邊的錶鏈接數據,右邊的表沒有數據的話則爲null
右鏈接是根據某個條件以及右邊的錶鏈接數據,左邊的表沒有數據的話則爲null
七、視圖和表的區別
視圖是已經編譯好的sql語句,是基於sql語句的結果集的可視化的表,而表不是
視圖是窗口,表示內容
視圖沒有實際的物理記錄,而表有
視圖的創建和刪除隻影響視圖自己,不影響對應的表
八、關係型數據庫的特色
數據集中控制
數據獨立性高
數據共享性好
數據冗餘度小
數據結構化
統一的數據保護能力
九、mysql數據庫都有哪些索引
普通索引:普通索引僅有一個功能:加速查找
惟一索引:惟一索引兩個功能:加速查找和惟一約束(可含null)
外鍵索引:外鍵索引兩個功能:加速查找和惟一約束(不可爲null)
聯合索引:聯合索引是將n個列組合成一個索引,應用場景:同時使用n列來進行查詢
十、存儲過程
存儲過程不容許執行return語句,可是能夠經過out參數返回多個值,存儲過程通常是做爲一個獨立的部分來執行,存儲過程是一個預編譯的SQL語句。
十一、sql優化
select句中避免使用 '*'
減小訪問數據庫的次數
刪除重複記錄
用where子句替代having子句
減小對錶的查詢
explain等
十二、char和vachar區別
char是固定長度,存儲須要空間12個字節,處理速度比vachar快,費內存空間
vachar是不固定長度,須要存儲空間13個字節,節約存儲空間
1三、Mechached與redis
mechached:只支持字符串,不能持久化,數據僅存在內存中,宕機或重啓數據將所有失效
不能進行分佈式擴展,文件沒法異步法。
優勢:mechached進程運行以後,會預申請一塊較大的內存空間,本身進行管理。
redis:支持服務器端的數據類型,redis與memcached相比來講,擁有更多的數據結構和併發支持更豐富的數據操做,可持久化。
五大類型數據:string、hash、list、set和有序集合,redis是單進程單線程的。
缺點:數據庫的容量受到物理內存的限制。
1四、sql注入
sql注入是比較常見的攻擊方式之一,針對編程員編程的疏忽,經過sql語句,實現帳號沒法登錄,甚至篡改數據庫。
防止:凡涉及到執行sql中有變量時,切記不要用拼接字符串的方法
1五、什麼是觸發器
觸發器是一種特殊的存儲過程,主要是經過事件來觸發而被執行的,他能夠強化約束,來維護數據庫的完整性和一致性,能夠跟蹤數據內的操做從而不容許未經許可的 更新和變化,能夠聯級運算。
只有表支持觸發器,視圖不支持觸發器
1六、遊標是什麼?
是對查詢出來的結果集做爲一個單元來有效的處理,遊標能夠定在該單元中的特定行,從結果集的當前行檢索一行或多行,能夠對結果集當前行作修改,
通常不使用遊標,可是須要逐條處理數據的時候,遊標顯得十分重要
1七、 數據庫支持多有標準的SQL數據類型,重要分爲三類
數值類型(tinyint,int,bigint,浮點數,bit)
字符串類型(char和vachar,enum,text,set)
日期類型(date,datetime,timestamp)
1八、mysql慢查詢
慢查詢對於跟蹤有問題的查詢頗有用,能夠分析出當前程序裏哪些sql語句比較耗費資源
慢查詢定義:
指mysql記錄全部執行超過long_query_time參數設定的時間值的sql語句,慢查詢日誌就是記錄這些sql的日誌。
mysql在windows系統中的配置文件通常是my.ini找到mysqld
log-slow-queries = F:\MySQL\log\mysqlslowquery.log 爲慢查詢日誌存放的位置,通常要有可寫權限
long_query_time = 2 2表示查詢超過兩秒才記錄
1九、memcached命中率
命中:能夠直接經過緩存獲取到須要的數據
不命中:沒法直接經過緩存獲取到想要的數據,須要再次查詢數據庫或者執行其餘的操做,緣由多是因爲緩存中根本不存在,或者緩存已通過期
緩存的命中率越高則表示使用緩存的收益越高,應額用的性能越好,抗病發能力越強
運行state命令能夠查看memcached服務的狀態信息,其中cmd—get表示總的get次數,get—hits表示命中次數,命中率=get—hits / cmd—get
20、Oracle和MySQL該如何選擇,爲何?
他們都有各自的優勢和缺點。考慮到時間因素,我傾向於MySQL
選擇MySQL而不選Oracle的緣由
MySQL開源
MySQL輕便快捷
MySQL對命令行和圖形界面的支持都很好
MySQL支持經過Query Browser進行管理
2一、什麼狀況下適合創建索引?
1.爲常常出如今關鍵字order by、group by、distinct後面的字段,創建索引
2.在union等集合操做的結果集字段上,創建索引,其創建索引的目的同上
3.爲常常用做查詢選擇的字段,創建索引
4.在常常用做錶鏈接的屬性上,創建索引
2二、數據庫底層是用什麼結構實現的,你大體畫一下
底層用B+數實現,結構圖參考:
http://blog.csdn.net/cjfeii/article/details/10858721
http://blog.csdn.net/tonyxf121/article/details/8393545
2三、sql語句應該考慮哪些安全性?
1.防止sql注入,對特殊字符進行轉義,過濾或者使用預編譯的sql語句綁定變量
2.最小權限原則,特別是不要用root帳戶,爲不一樣的類型的動做或者組建使用不一樣的帳戶
3.當sql運行出錯時,不要把數據庫返回的錯誤信息所有顯示給用戶,以防止泄漏服務器和數據庫相關信息
2四、數據庫事物有哪幾種?
隔離性、持續性、一致性、原子性
2五、MySQ數據表在什麼狀況下容易損壞?
服務器忽然斷電致使數據文件損壞
強制關機,沒有先關閉mysq服務器等
2六、drop,delete與truncate的區別
drop直接刪除表
truncate刪除表中數據,再插入時自增加id又從1開始
delete刪除表中數據,能夠加where子句
2七、數據庫範式
1.第一範式:就是無重複的列
2.第二範式:就是非主屬性非部分依賴於主關鍵字
3.第三範式:就是屬性不依賴於其餘非主屬性(消除冗餘)
2八、MySQL鎖類型
根據鎖的類型分:能夠分爲共享鎖、排他鎖、意向共享鎖和意向排他鎖
根據鎖的粒度分:能夠分爲行鎖、表鎖
對於mysql而言,事務機制更可能是靠底層的存儲引擎來實現的,所以,mysql層面只有表鎖,
而支持事物的innodb存儲引發則實現了行鎖(在行相應的索引記錄上的鎖)
說明:對於更新操做(讀不上鎖),只有走索引纔可能上行鎖
MVCC(多版本併發控制)併發控制機制下,任何操做都不會阻塞讀取操做,
讀取操做也不會阻塞任何操做,只由於讀不上鎖
共享鎖:由讀表操做加上的鎖,加鎖後其餘用戶只能獲取該表或行的共享鎖,不能獲取排他鎖,
也就是說只能讀不能寫
排他鎖:由寫表操做加上的鎖,加鎖後其餘用戶不能獲取該表或該行的任何鎖,典型mysql事物中的更新操做
意向共享鎖(IS):事物打算給數據行加行共享鎖,事物在給一個數據行加共享鎖前必須先取得該表的IS鎖
意向排他鎖(IX):事物打算給數據行加行排他鎖,事物在給一個數據行家排他鎖前必須先取得該表的IX鎖
2九、如何解決MYSQL數據庫中文亂碼問題?
1.在數據庫安裝的時候指定字符集
2.若是在按完了之後能夠更改配置文件
3.創建數據庫時候:指定字符集類型
4.建表的時候也指定字符集
30、數據庫應用系統設計
1.規劃
2.需求分析
3.概念模型設計
4.邏輯設計
5.物理設計
6. 程序編制及調試
7.運行及維護
1、爲何用自增列做爲主鍵
一、若是咱們定義了主鍵(PRIMARY KEY),那麼InnoDB會選擇主鍵做爲彙集索引、若是沒有顯式定義主鍵,則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引、若是也沒有這樣的惟一索引,則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增,這個ROWID不像ORACLE的ROWID那樣可引用,是隱含的)。
二、數據記錄自己被存於主索引(一顆B+Tree)的葉子節點上。這就要求同一個葉子節點內(大小爲一個內存頁或磁盤頁)的各條數據記錄按主鍵順序存放,所以每當有一條新的記錄插入時,MySQL會根據其主鍵將其插入適當的節點和位置,若是頁面達到裝載因子(InnoDB默認爲15/16),則開闢一個新的頁(節點)
三、若是表使用自增主鍵,那麼每次插入新的記錄,記錄就會順序添加到當前索引節點的後續位置,當一頁寫滿,就會自動開闢一個新的頁
四、若是使用非自增主鍵(若是身份證號或學號等),因爲每次插入主鍵的值近似於隨機,所以每次新紀錄都要被插到現有索引頁得中間某個位置,此時MySQL不得不爲了將新記錄插到合適位置而移動數據,甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉,此時又要從磁盤上讀回來,這增長了不少開銷,同時頻繁的移動、分頁操做形成了大量的碎片,獲得了不夠緊湊的索引結構,後續不得不經過OPTIMIZE TABLE來重建表並優化填充頁面。
2、爲何使用數據索引能提升效率
一、數據索引的存儲是有序的
二、在有序的狀況下,經過索引查詢一個數據是無需遍歷索引記錄的
三、極端狀況下,數據索引的查詢效率爲二分法查詢效率,趨近於 log2(N)
3、B+樹索引和哈希索引的區別
B+樹是一個平衡的多叉樹,從根節點到每一個葉子節點的高度差值不超過1,並且同層級的節點間有指針相互連接,是有序的
哈希索引就是採用必定的哈希算法,把鍵值換算成新的哈希值,檢索時不須要相似B+樹那樣從根節點到葉子節點逐級查找,只需一次哈希算法便可,是無序的
4、哈希索引的優點:
一、等值查詢。哈希索引具備絕對優點(前提是:沒有大量重複鍵值,若是大量重複鍵值時,哈希索引的效率很低,由於存在所謂的哈希碰撞問題。)
5、哈希索引不適用的場景:
一、不支持範圍查詢
二、不支持索引完成排序
三、不支持聯合索引的最左前綴匹配規則
一般,B+樹索引結構適用於絕大多數場景,像下面這種場景用哈希索引才更有優點:
在HEAP表中,若是存儲的數據重複度很低(也就是說基數很大),對該列數據以等值查詢爲主,沒有範圍查詢、沒有排序的時候,特別適合採用哈希索引,例如這種SQL:
select id,name from table where name='李明'; — 僅等值查詢
而經常使用的InnoDB引擎中默認使用的是B+樹索引,它會實時監控表上索引的使用狀況,若是認爲創建哈希索引能夠提升查詢效率,則自動在內存中的「自適應哈希索引緩衝區」創建哈希索引(在InnoDB中默認開啓自適應哈希索引),經過觀察搜索模式,MySQL會利用index key的前綴創建哈希索引,若是一個表幾乎大部分都在緩衝池中,那麼創建一個哈希索引可以加快等值查詢。
注意:在某些工做負載下,經過哈希索引查找帶來的性能提高遠大於額外的監控索引搜索狀況和保持這個哈希表結構所帶來的開銷。但某些時候,在負載高的狀況下,自適應哈希索引中添加的read/write鎖也會帶來競爭,好比高併發的join操做。like操做和%的通配符操做也不適用於自適應哈希索引,可能要關閉自適應哈希索引。
6、B樹和B+樹的區別
一、B樹,每一個節點都存儲key和data,全部節點組成這棵樹,而且葉子節點指針爲nul,葉子結點不包含任何關鍵字信息。
二、B+樹,全部的葉子結點中包含了所有關鍵字的信息,及指向含有這些關鍵字記錄的指針,且葉子結點自己依關鍵字的大小自小而大的順序連接,全部的非終端結點能夠當作是索引部分,結點中僅含有其子樹根結點中最大(或最小)關鍵字。 (而B 樹的非終節點也包含須要查找的有效信息)
7、爲何說B+比B樹更適合實際應用中操做系統的文件索引和數據庫索引?
一、B+的磁盤讀寫代價更低B+的內部結點並無指向關鍵字具體信息的指針。所以其內部結點相對B樹更小。若是把全部同一內部結點的關鍵字存放在同一盤塊中,那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的須要查找的關鍵字也就越多。相對來講IO讀寫次數也就下降了。
二、B+-tree的查詢效率更加穩定因爲非終結點並非最終指向文件內容的結點,而只是葉子結點中關鍵字的索引。因此任何關鍵字的查找必須走一條從根結點到葉子結點的路。全部關鍵字查詢的路徑長度相同,致使每個數據的查詢效率至關。
8、MySQL聯合索引
一、聯合索引是兩個或更多個列上的索引。對於聯合索引:Mysql從左到右的使用索引中的字段,一個查詢能夠只使用索引中的一部份,但只能是最左側部分。例如索引是key index (a,b,c). 能夠支持a 、 a,b 、 a,b,c 3種組合進行查找,但不支持 b,c進行查找 .當最左側字段是常量引用時,索引就十分有效。
二、利用索引中的附加列,您能夠縮小搜索的範圍,但使用一個具備兩列的索引 不一樣於使用兩個單獨的索引。複合索引的結構與電話簿相似,人名由姓和名構成,電話簿首先按姓氏對進行排序,而後按名字對有相同姓氏的人進行排序。若是您知 道姓,電話簿將很是有用;若是您知道姓和名,電話簿則更爲有用,但若是您只知道名不姓,電話簿將沒有用處。
9、什麼狀況下應不建或少建索引
一、表記錄太少
二、常常插入、刪除、修改的表
三、數據重複且分佈平均的表字段,假如一個表有10萬行記錄,有一個字段A只有T和F兩種值,且每一個值的分佈機率大約爲50%,那麼對這種表A字段建索引通常不會提升數據庫的查詢速度。
四、常常和主字段一塊查詢但主字段索引值比較多的表字段
10、什麼是表分區?
表分區,是指根據必定規則,將數據庫中的一張表分解成多個更小的,容易管理的部分。從邏輯上看,只有一張表,可是底層倒是由多個物理分區組成。
11、表分區與分表的區別
分表:指的是經過必定規則,將一張表分解成多張不一樣的表。好比將用戶訂單記錄根據時間成多個表。
分表與分區的區別在於:分區從邏輯上來說只有一張表,而分表則是將一張表分解成多張表。
12、表分區有什麼好處?
一、分區表的數據能夠分佈在不一樣的物理設備上,從而高效地利用多個硬件設備。 2. 和單個磁盤或者文件系統相比,能夠存儲更多數據
二、優化查詢。在where語句中包含分區條件時,能夠只掃描一個或多個分區表來提升查詢效率;涉及sum和count語句時,也能夠在多個分區上並行處理,最後彙總結果。
三、分區表更容易維護。例如:想批量刪除大量數據能夠清除整個分區。
四、可使用分區表來避免某些特殊的瓶頸,例如InnoDB的單個索引的互斥訪問,ext3問價你係統的inode鎖競爭等。
十3、分區表的限制因素
一、一個表最多隻能有1024個分區
二、MySQL5.1中,分區表達式必須是整數,或者返回整數的表達式。在MySQL5.5中提供了非整數表達式分區的支持。
三、若是分區字段中有主鍵或者惟一索引的列,那麼多有主鍵列和惟一索引列都必須包含進來。即:分區字段要麼不包含主鍵或者索引列,要麼包含所有主鍵和索引列。
四、分區表中沒法使用外鍵約束
五、MySQL的分區適用於一個表的全部數據和索引,不能只對表數據分區而不對索引分區,也不能只對索引分區而不對錶分區,也不能只對表的一部分數據分區。
十4、如何判斷當前MySQL是否支持分區?
命令:show variables like '%partition%' 運行結果:
mysql> show variables like '%partition%';
+-------------------+-------+| Variable_name | Value |+-------------------+-------+| have_partitioning | YES |+-------------------+-------+1 row in set (0.00 sec)
have_partintioning 的值爲YES,表示支持分區。
十5、MySQL支持的分區類型有哪些?
一、RANGE分區: 這種模式容許將數據劃分不一樣範圍。例如能夠將一個表經過年份劃分紅若干個分區
二、LIST分區: 這種模式容許系統經過預約義的列表的值來對數據進行分割。按照List中的值分區,與RANGE的區別是,range分區的區間範圍值是連續的。
三、HASH分區 :這中模式容許經過對錶的一個或多個列的Hash Key進行計算,最後經過這個Hash碼不一樣數值對應的數據區域進行分區。例如能夠創建一個對錶主鍵進行分區的表。
四、KEY分區 :上面Hash模式的一種延伸,這裏的Hash Key是MySQL系統產生的。
十6、四種隔離級別
一、Serializable (串行化):可避免髒讀、不可重複讀、幻讀的發生。
二、Repeatable read (可重複讀):可避免髒讀、不可重複讀的發生。
三、Read committed (讀已提交):可避免髒讀的發生。
四、Read uncommitted (讀未提交):最低級別,任何狀況都沒法保證。
十7、關於MVVC
MySQL InnoDB存儲引擎,實現的是基於多版本的併發控制協議——MVCC (Multi-Version Concurrency Control) (注:與MVCC相對的,是基於鎖的併發控制,Lock-Based Concurrency Control)。MVCC最大的好處:讀不加鎖,讀寫不衝突。在讀多寫少的OLTP應用中,讀寫不衝突是很是重要的,極大的增長了系統的併發性能,現階段幾乎全部的RDBMS,都支持了MVCC。
一、LBCC:Lock-Based Concurrency Control,基於鎖的併發控制。
二、MVCC:Multi-Version Concurrency Control,基於多版本的併發控制協議。純粹基於鎖的併發機制併發量低,MVCC是在基於鎖的併發控制上的改進,主要是在讀操做上提升了併發量。
十8、在MVCC併發控制中,讀操做能夠分紅兩類:
一、快照讀 (snapshot read):讀取的是記錄的可見版本 (有多是歷史版本),不用加鎖(共享讀鎖s鎖也不加,因此不會阻塞其餘事務的寫)。
二、當前讀 (current read):讀取的是記錄的最新版本,而且,當前讀返回的記錄,都會加上鎖,保證其餘事務不會再併發修改這條記錄。
十9、行級鎖定的優勢:
一、當在許多線程中訪問不一樣的行時只存在少許鎖定衝突。
二、回滾時只有少許的更改
三、能夠長時間鎖定單一的行。
二10、行級鎖定的缺點:
一、比頁級或表級鎖定佔用更多的內存。
二、當在表的大部分中使用時,比頁級或表級鎖定速度慢,由於你必須獲取更多的鎖。
三、若是你在大部分數據上常常進行GROUP BY操做或者必須常常掃描整個表,比其它鎖定明顯慢不少。
四、用高級別鎖定,經過支持不一樣的類型鎖定,你也能夠很容易地調節應用程序,由於其鎖成本小於行級鎖定。
二11、MySQL優化
一、開啓查詢緩存,優化查詢
二、explain你的select查詢,這能夠幫你分析你的查詢語句或是表結構的性能瓶頸。EXPLAIN 的查詢結果還會告訴你你的索引主鍵被如何利用的,你的數據表是如何被搜索和排序的
三、當只要一行數據時使用limit 1,MySQL數據庫引擎會在找到一條數據後中止搜索,而不是繼續日後查少下一條符合記錄的數據
四、爲搜索字段建索引
五、使用 ENUM 而不是 VARCHAR,若是你有一個字段,好比「性別」,「國家」,「民族」,「狀態」或「部門」,你知道這些字段的取值是有限並且固定的,那麼,你應該使用 ENUM 而不是VARCHAR。
六、Prepared StatementsPrepared Statements很像存儲過程,是一種運行在後臺的SQL語句集合,咱們能夠從使用 prepared statements 得到不少好處,不管是性能問題仍是安全問題。Prepared Statements 能夠檢查一些你綁定好的變量,這樣能夠保護你的程序不會受到「SQL注入式」攻擊
七、垂直分表
八、選擇正確的存儲引擎
二12、key和index的區別
一、key 是數據庫的物理結構,它包含兩層意義和做用,一是約束(偏重於約束和規範數據庫的結構完整性),二是索引(輔助查詢用的)。包括primary key, unique key, foreign key 等
二、index是數據庫的物理結構,它只是輔助查詢的,它建立時會在另外的表空間(mysql中的innodb表空間)以一個相似目錄的結構存儲。索引要分類的話,分爲前綴索引、全文本索引等;
二十3、Mysql 中 MyISAM 和 InnoDB 的區別有哪些?
區別:
一、InnoDB支持事務,MyISAM不支持,對於InnoDB每一條SQL語言都默認封裝成事務,自動提交,這樣會影響速度,因此最好把多條SQL語言放在begin和commit之間,組成一個事務;
二、InnoDB支持外鍵,而MyISAM不支持。對一個包含外鍵的InnoDB錶轉爲MYISAM會失敗;
三、InnoDB是彙集索引,數據文件是和索引綁在一塊兒的,必需要有主鍵,經過主鍵索引效率很高。可是輔助索引須要兩次查詢,先查詢到主鍵,而後再經過主鍵查詢到數據。所以,主鍵不該該過大,由於主鍵太大,其餘索引也都會很大。而MyISAM是非彙集索引,數據文件是分離的,索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。
四、InnoDB不保存表的具體行數,執行select count(*) from table時須要全表掃描。而MyISAM用一個變量保存了整個表的行數,執行上述語句時只須要讀出該變量便可,速度很快;
五、Innodb不支持全文索引,而MyISAM支持全文索引,查詢效率上MyISAM要高;
如何選擇:
一、是否要支持事務,若是要請選擇innodb,若是不須要能夠考慮MyISAM;
二、若是表中絕大多數都只是讀查詢,能夠考慮MyISAM,若是既有讀寫也挺頻繁,請使用InnoDB。
三、系統奔潰後,MyISAM恢復起來更困難,可否接受;
四、MySQL5.5版本開始Innodb已經成爲Mysql的默認引擎(以前是MyISAM),說明其優點是有目共睹的,若是你不知道用什麼,那就用InnoDB,至少不會差。
二十4、數據庫表建立注意事項
一、字段名及字段配製合理性
剔除關係不密切的字段;
字段命名要有規則及相對應的含義(不要一部分英文,一部分拼音,還有相似a.b.c這樣不明含義的字段);
字段命名儘可能不要使用縮寫(大多數縮寫都不能明確字段含義);
字段不要大小寫混用(想要具備可讀性,多個英文單詞可以使用下劃線形式鏈接);
字段名不要使用保留字或者關鍵字;
保持字段名和類型的一致性;
慎重選擇數字類型;
給文本字段留足餘量;
二、系統特殊字段處理及建成後建議
添加刪除標記(例如操做人、刪除時間);
創建版本機制;
三、表結構合理性配置
多型字段的處理,就是表中是否存在字段可以分解成更小獨立的幾部分(例如:人能夠分爲男人和女人);
多值字段的處理,能夠將表分爲三張表,這樣使得檢索和排序更加有調理,且保證數據的完整性!
四、其它建議
對於大數據字段,獨立表進行存儲,以便影響性能(例如:簡介字段);
使用varchar類型代替char,由於varchar會動態分配長度,char指定長度是固定的;
給表建立主鍵,對於沒有主鍵的表,在查詢和索引定義上有必定的影響;
避免表字段運行爲null,建議設置默認值(例如:int類型設置默認值爲0)在索引查詢上,效率立顯;
創建索引,最好創建在惟一和非空的字段上,創建太多的索引對後期插入、更新都存在必定的影響(考慮實際狀況來建立);