沒什么意思，就是一個變量名表示表的前綴
創(chuàng)新互聯(lián)建站提供高防服務(wù)器租用、云服務(wù)器、香港服務(wù)器、遂寧聯(lián)通機房等
一般MySQL里面都在在表前面添加一個前綴來區(qū)分表的作用。
就是像FI項目用user表，就寫成FI_user
所以在有些系統(tǒng)中mysql_table_prefix=FI
前綴索引顧名思義，定義字符串的一部分當做索引，而不是把整個字符串當做索引。默認地，如果你創(chuàng)建索引的語句不指定前綴長度，那么索引就會包含整個字符串。
假設(shè)一張表有 id,name,email 2個字段
1.創(chuàng)建email列的普通索引應(yīng)該是： alter table T add index idx_email1( email )
2.前綴索引的創(chuàng)建規(guī)則為： alter table table T add index idx_email2( email(6) )
當然第一索引包含是的整個字符串，第二個是該字段前6個字節(jié)（注意是字節(jié)）
對于這2中索引，B+樹怎么存儲呢？
INSERT INTO T (email) VALUES ('瞎子','zhangsh1234@163.com'), ('劍圣','lisi1998883@163.com'), ('露娜','zhangssxyz@163.com'), ('李白','zhangsy1998@163.com'), ('韓信','zhaq5481993@163.com'), ('百里玄策','hhaq5481993@163.com');
【誰還不是個野王啊】
普通索引存儲為：
是的你沒看錯，前綴索引那顆樹上的存儲的是email的前6位字節(jié)，也就是你創(chuàng)建前綴索引時指定的前綴字節(jié)長度。2種樹相比，前綴索引存儲了更少的數(shù)據(jù)，那么他所耗費的空間也就相比較少，這正是他的一個優(yōu)點。同樣的也就相對的增加了掃描行數(shù)。
什么增加了掃描行數(shù)？？？？ 這是為什么呢？
那么小朋友咱們一起來看下吧。
假設(shè)SQL如此這般： select id,name,email from T where email = 'zhangsh1234@163.com'
那么這2個SQL，應(yīng)該怎么操作呢。
idx_email1:
2.到主鍵上查到主鍵為ID1的，判斷email值是否正確【為什么判斷呢，其實我理解是為了二次判斷保證數(shù)據(jù)一致性吧，比較官方的解釋尚未找到】，正確放入結(jié)果集
3.取 idx_email1 索引樹上剛剛查到的位置的下一條記錄，如此往復(fù)。
循環(huán)過程中，需要回主鍵取1次數(shù)據(jù)，所以系統(tǒng)可以認為只掃描了一行【1次是數(shù)第一棵樹數(shù)出來的】
idx_email2:
1.從 索引數(shù)上找到滿足索引值為 'zhangs'的該記錄，取得 ID1的值
2.到主鍵上查到主鍵值是 ID1 的行，判斷出 email 的值是’ zhangsh1234@xxx.com ’，這行記錄放入結(jié)果集【不是要的值，丟棄，進行下一步】
3.取 idx_email2 上剛剛查到的位置的下一條記錄,重復(fù)以上步驟
在這個過程中，要回主鍵索引取 3 次數(shù)據(jù)，也就是掃描了 3 行。通過這個對比，你很容易就可以發(fā)現(xiàn)，使用前綴索引后，可能會導(dǎo)致查詢語句讀數(shù)據(jù)的次數(shù)變多。
但是，對于這個查詢語句來說，如果你定義的 idx_email2 不是 email(6) 而是 email(8），也就是說取 email 字段的前 8 個字節(jié)來構(gòu)建索引的話，即滿足前綴’zhangsh’的記錄只有一個，也能夠直接查到 ID1，只掃描一行就結(jié)束了。也就是說使用前綴索引，定義好長度，就可以做到既節(jié)省空間，又不用額外增加太多的查詢成本。
那么問題來了，到底定義多長才算是合理呢？
一般的定義原則是 count(distinct(columnName))/count(*) ,當前綴索引【count(distinct(columnName(length)))，length是你想要創(chuàng)建列的前綴字節(jié)長度】越接近此值越好，當有多個前綴字節(jié)都一樣且都等于這個值時怎么選擇呢，當然是 字節(jié)越少越好了哈，字節(jié)越少越省空間。索引選取的越長，占用的磁盤空間就越大，相同的數(shù)據(jù)頁能放下的索引值就越少，搜索的效率也就會越低。
count(distinct(columnName(length))) 翻譯到SQL 為： count(dictinct(left(colunmName, length)))
前面我們說了使用前綴索引可能會增加掃描行數(shù)，這會影響到性能。其實，前綴索引的影響不止如此，我們再看一下另外一個場景。
來呀，上SQL： select id,email from T where email='zhangsh1234@163.com'
如果按照email全字段索引，那么此SQL 是不需要回表的【為什么不需要回表？兄嘚，這個相當于覆蓋索引了哈】
那么如果按照前綴索引是否需要回表呢？答案是的。
因為當判斷前6個字節(jié)相等后，需要拿到id 回表拿到email的全部內(nèi)容進行比較，如果不相同，丟棄這行，否則加入結(jié)果集。
那么有人會問了，我把長度放大點，包含所有字節(jié)不就好了嗎？
那么此時會有如下問題。
1.當你此時的長度是囊括了全字段，但是系統(tǒng)是不知道的，他還是需要回表再次判斷的，去確定前綴索引的定義是否截斷了完整信息。
2.此時長度是夠了，那么能肯定因為業(yè)務(wù)日后不會增加長度嗎？
3.盡可能的加長長度，還不如直接建立全字段索引呢
綜上，使用前綴索引就用不上覆蓋索引對查詢性能的優(yōu)化了，這也是你在選擇是否使用前綴索引時需要考慮的一個因素。
前面說到的是，可以根據(jù)字段前面幾個字節(jié)進行查詢的，那么對于身份證這種，一共 18 位，其中前 6 位是地址碼，所以同一個縣的人的身份證號前 6 位一般會是相同的。
或許你會說，多弄幾個字節(jié)不就好嗎？那么請問下自己為什么使用前綴索引呢，不就是為了節(jié)省空間嗎？
那么這么做合適嗎？ 不合適對嗎？ 乖~，快去反省下吧
那么采用前綴索引顯示是不行的，那么如果用前綴索引怎么辦呢，聰明的你應(yīng)該已經(jīng)猜到了，采用倒敘存儲，然后建立前綴索引。
放到SQL 中就應(yīng)該是這樣的： select field_list from t where id_card = reverse('id_card_string');
當然了，這種邏輯建議放到業(yè)務(wù)邏輯中實現(xiàn)，而不是放到SQL 中。
按照上述第4節(jié)的內(nèi)容，有人或許會有另一個想法，還倒敘建立前綴索引復(fù)雜不，hash索引或者hash字段不香嗎？
有人會問了，為什么要在創(chuàng)建一個值來存儲hash值呢，如果不存儲你知道原值是什么嗎？ 同時hash算法是有一定重復(fù)可能的（hash值碰撞）
【可以了解下partition算法哦:[ 】。如果重復(fù)了，不存儲原值，你是無法判斷出正確數(shù)據(jù)的。
注：【hash字段不代表hash索引，hash索引原理正在快馬加鞭】，簡單說下hash索引，hash索引不需要創(chuàng)建一個值來存儲hash值，而是有hasn表來存儲【hash值碰撞時，由一個鏈表來搞定了】，存儲的內(nèi)容為 hash值和每行的行指針 。
說回來啊，跑題了
查詢時： select field_list from t where id_card_crc=crc32('id_card_string') and id_card='id_card_string'
不過有個問題相信你也想到了，不管是hash存儲值還是hash索引都是不支持范圍查詢的。
來總結(jié)下這2個優(yōu)缺點吧
1.從占用空間來看呢，倒敘索引不需要額外開辟存儲空間，而hash字段需要額外的一個字段，所以從這點上看倒敘索引更勝一籌，NO!并不準確,如果前綴長度過長，那么這2個情況額外的空間也就相差無幾了
3.從查詢效率上看，使用 hash 字段方式的查詢性能相對更穩(wěn)定一些。因為 crc32 算出來的值雖然有沖突的概率，但是概率非常小，可以認為每次查詢的平均掃描行數(shù)接近 1。而倒序存儲方式畢竟還是用的前綴索引的方式，也就是說還是會增加掃描行數(shù)
1.全字段完整索引比較占空間，但是而走覆蓋索引
2.前綴索引，節(jié)省空間，但會增加掃描 次數(shù) 并且不能使用覆蓋索引【每次都需回表校驗】
3.倒序存儲，再創(chuàng)建前綴索引，用于繞過字符串本身前綴的區(qū)分度不夠的問題?！镜箶⒎椒ń⒎诺綐I(yè)務(wù)邏輯中】
4.hash字段索引，相比前綴索引性能較為穩(wěn)定，但是有額外的存儲空間和計算消耗，同時也 不 支持范圍查詢
1. 概述
MySQL數(shù)據(jù)庫的導(dǎo)入，有兩種方法：
1) 先導(dǎo)出數(shù)據(jù)庫SQL腳本，再導(dǎo)入；
2) 直接拷貝數(shù)據(jù)庫目錄和文件。
在不同操作系統(tǒng)或MySQL版本情況下，直接拷貝文件的方法可能會有不兼容的情況發(fā)生。
所以一般推薦用SQL腳本形式導(dǎo)入。下面分別介紹兩種方法。
2. 方法一 SQL腳本形式
操作步驟如下：
2.1. 導(dǎo)出SQL腳本
在原數(shù)據(jù)庫服務(wù)器上，可以用phpMyAdmin工具，或者mysqldump(mysqldump命令位于mysql/bin/目錄中)命令行，導(dǎo)出SQL腳本。
2.1.1 用phpMyAdmin工具
導(dǎo)出選項中，選擇導(dǎo)出“結(jié)構(gòu)”和“數(shù)據(jù)”，不要添加“Drop DATABASE”和“Drop TABLE”選項。
選中“另存為文件”選項，如果數(shù)據(jù)比較多，可以選中“gzipped”選項。
將導(dǎo)出的SQL文件保存下來。
2.1.2 用mysqldump命令行
命令格式
mysqldump -u用戶名 -p 數(shù)據(jù)庫名 數(shù)據(jù)庫名.sql
范例：
mysqldump -uroot -p abc abc.sql
（導(dǎo)出數(shù)據(jù)庫abc到abc.sql文件）
提示輸入密碼時，輸入該數(shù)據(jù)庫用戶名的密碼。
2.2. 創(chuàng)建空的數(shù)據(jù)庫
通過主控界面/控制面板，創(chuàng)建一個數(shù)據(jù)庫。假設(shè)數(shù)據(jù)庫名為abc，數(shù)據(jù)庫全權(quán)用戶為abc_f。
2.3. 將SQL腳本導(dǎo)入執(zhí)行
同樣是兩種方法，一種用phpMyAdmin（mysql數(shù)據(jù)庫管理）工具，或者mysql命令行。
2.3.1 用phpMyAdmin工具
從控制面板，選擇創(chuàng)建的空數(shù)據(jù)庫，點“管理”，進入管理工具頁面。
在"SQL"菜單中，瀏覽選擇剛才導(dǎo)出的SQL文件，點擊“執(zhí)行”以上載并執(zhí)行。
注意：phpMyAdmin對上載的文件大小有限制，php本身對上載文件大小也有限制，如果原始sql文件
比較大，可以先用gzip對它進行壓縮，對于sql文件這樣的文本文件，可獲得1:5或更高的壓縮率。
gzip使用方法：
# gzip xxxxx.sql
得到
xxxxx.sql.gz文件。
2.3.2 用mysql命令行
命令格式
mysql -u用戶名 -p 數(shù)據(jù)庫名 數(shù)據(jù)庫名.sql
范例：
mysql -uabc_f -p abc abc.sql
（導(dǎo)入數(shù)據(jù)庫abc從abc.sql文件）
提示輸入密碼時，輸入該數(shù)據(jù)庫用戶名的密碼。
3 方法二 直接拷貝
如果數(shù)據(jù)庫比較大，可以考慮用直接拷貝的方法，但不同版本和操作系統(tǒng)之間可能不兼容，要慎用。
3.1 準備原始文件
用tar打包為一個文件
3.2 創(chuàng)建空數(shù)據(jù)庫
3.3 解壓
在臨時目錄中解壓，如：
cd /tmp
tar zxf mydb.tar.gz
3.4 拷貝
將解壓后的數(shù)據(jù)庫文件拷貝到相關(guān)目錄
cd mydb/
cp * /var/lib/mysql/mydb/
對于FreeBSD:
cp * /var/db/mysql/mydb/
3.5 權(quán)限設(shè)置
將拷貝過去的文件的屬主改為mysql:mysql，權(quán)限改為660
chown mysql:mysql /var/lib/mysql/mydb/*
chmod 660 /var/lib/mysql/mydb/
江西新華電腦學(xué)院專業(yè)為你解答計算機類疑惑，望對你有幫助，謝謝采納^-^
重慶分公司
重慶分公司
