mysql 如何存儲(chǔ)連線(xiàn)題

簡(jiǎn)單的方法是你在存儲(chǔ)過(guò)程中打印SQL,

河池網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),河池網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為河池上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的河池做網(wǎng)站的公司定做！

set y_sql=concat_ws(' ','insert','into',tmp4data,'value','(',var1,var2,')');

select y_sql;

看看y_sql合并生什么， 其次在動(dòng)態(tài)SQL過(guò)程中， 你定義的tmp4data到底是變量還是表的名稱(chēng)，如果是名稱(chēng)就需要添加分號(hào)

在Mysql中，把多個(gè)值以字符串組合的方式保存到一列和把各個(gè)值單獨(dú)保存到一條記錄的綜合效率分析。

索引的目的在于提高查詢(xún)效率，可以類(lèi)比字典，如果要查“mysql”這個(gè)單詞，我們肯定需要定位到m字母，然后從下往下找到y(tǒng)字母，再找到剩下的sql。如果沒(méi)有索引，那么你可能需要把所有單詞看一遍才能找到你想要的。

1.索引的優(yōu)點(diǎn)

假設(shè)你擁有三個(gè)未索引的表t1、t2和t3，每個(gè)表都分別包含數(shù)據(jù)列i1、i2和i3，并且每個(gè)表都包含了1000條數(shù)據(jù)行，其序號(hào)從1到1000。查找某些值匹配的數(shù)據(jù)行組合的查詢(xún)可能如下所示：

SELECT t1.i1, t2.i2, t3.i3 FROM t1, t2, t3 WHERE t1.i1 = t2.i2 AND t2.i1 = t3.i3;

這個(gè)查詢(xún)的結(jié)果應(yīng)該是1000行，每個(gè)數(shù)據(jù)行包含三個(gè)相等的值。如果在沒(méi)有索引的情況下處理這個(gè)查詢(xún)，那么如果我們不對(duì)這些表進(jìn)行全部地掃描，我們是沒(méi)有辦法知道哪些數(shù)據(jù)行含有哪些值的。因此你必須嘗試所有的組合來(lái)查找符合WHERE條件的記錄?？赡艿慕M合的數(shù)量是1000 x 1000 x 1000（10億?。?，它是匹配記錄的數(shù)量的一百萬(wàn)倍。這就浪費(fèi)了大量的工作。這個(gè)例子顯示，如果沒(méi)有使用索引，隨著表的記錄不斷增長(zhǎng)，處理這些表的聯(lián)結(jié)所花費(fèi)的時(shí)間增長(zhǎng)得更快，導(dǎo)致性能很差。我們可以通過(guò)索引這些數(shù)據(jù)表來(lái)顯著地提高速度，因?yàn)樗饕尣樵?xún)采用如下所示的方式來(lái)處理：

1．選擇表t1中的第一行并查看該數(shù)據(jù)行的值。

2．使用表t2上的索引，直接定位到與t1的值匹配的數(shù)據(jù)行。類(lèi)似地，使用表t3上的索引，直接定位到與表t2的值匹配的數(shù)據(jù)行。

3．處理表t1的下一行并重復(fù)前面的過(guò)程。執(zhí)行這樣的操作直到t1中的所有數(shù)據(jù)行都被檢查過(guò)。

在這種情況下，我們?nèi)匀粚?duì)表t1執(zhí)行了完整的掃描，但是我們可以在t2和t3上執(zhí)行索引查找，從這些表中直接地獲取數(shù)據(jù)行。理論上采用這種方式運(yùn)行上面的查詢(xún)會(huì)快一百萬(wàn)倍。當(dāng)然這個(gè)例子是為了得出結(jié)論來(lái)人為建立的。然而，它解決的問(wèn)題卻是現(xiàn)實(shí)的，給沒(méi)有索引的表添加索引通常會(huì)獲得驚人的性能提高。

-

2.索引的代價(jià)

首先，索引加快了檢索的速度，但是減慢了插入和刪除的速度，同時(shí)還減慢了更新被索引的數(shù)據(jù)列中的值的速度。也就是說(shuō)，索引減慢了大多數(shù)涉及寫(xiě)操作的速度。發(fā)生這種現(xiàn)象的原因在于寫(xiě)入一條記錄的時(shí)候不但需要寫(xiě)入數(shù)據(jù)行，還需要改變所有的索引。數(shù)據(jù)表帶有的索引越多，需要做出的修改就越多，平均性能的降低程度也就越大。在本文的”高效率載入數(shù)據(jù)”部分中，我們將更細(xì)致地了解這些現(xiàn)象并找出處理方法。

其次，索引會(huì)花費(fèi)磁盤(pán)空間，多個(gè)索引相應(yīng)地花費(fèi)更多的磁盤(pán)空間。這可能導(dǎo)致更快地到達(dá)數(shù)據(jù)表的大小限制：

· 對(duì)于MyISAM表，頻繁地索引可能引起索引文件比數(shù)據(jù)文件更快地達(dá)到最大限制。

· 對(duì)于BDB表，它把數(shù)據(jù)和索引值一起存儲(chǔ)在同一個(gè)文件中，添加索引引起這種表更快地達(dá)到最大文件限制。

· 在InnoDB的共享表空間中分配的所有表都競(jìng)爭(zhēng)使用相同的公共空間池，因此添加索引會(huì)更快地耗盡表空間中的存儲(chǔ)。但是，與MyISAM和BDB表使用的文件不同，InnoDB共享表空間并不受操作系統(tǒng)的文件大小限制，因?yàn)槲覀兛梢园阉渲贸墒褂枚鄠€(gè)文件。只要有額外的磁盤(pán)空間，你就可以通過(guò)添加新組件來(lái)擴(kuò)展表空間。

使用單獨(dú)表空間的InnoDB表與BDB表受到的約束是一樣的，因?yàn)樗臄?shù)據(jù)和索引值都存儲(chǔ)在單個(gè)文件中。

這些要素的實(shí)際含義是：如果你不需要使用特殊的索引幫助查詢(xún)執(zhí)行得更快，就不要建立索引。

3.選擇索引

假設(shè)你已經(jīng)知道了建立索引的語(yǔ)法，但是語(yǔ)法不會(huì)告訴你數(shù)據(jù)表應(yīng)該如何索引。這要求我們考慮數(shù)據(jù)表的使用方式。這一部分指導(dǎo)你如何識(shí)別出用于索引的備選數(shù)據(jù)列，以及如何最好地建立索引：

用于搜索、排序和分組的索引數(shù)據(jù)列并不僅僅是用于輸出顯示的。換句話(huà)說(shuō)，用于索引的最好的備選數(shù)據(jù)列是那些出現(xiàn)在WHERE子句、join子句、ORDER BY或GROUP BY子句中的列。僅僅出現(xiàn)在SELECT關(guān)鍵字后面的輸出數(shù)據(jù)列列表中的數(shù)據(jù)列不是很好的備選列：

SELECT col_a - 不是備選列 FROM tbl1 LEFT JOIN tbl2 ON tbl1.col_b = tbl2.col_c - 備選列 WHERE col_d = expr; - 備選列

當(dāng)然，顯示的數(shù)據(jù)列與WHERE子句中使用的數(shù)據(jù)列也可能相同。我們的觀點(diǎn)是輸出列表中的數(shù)據(jù)列本質(zhì)上不是用于索引的很好的備選列。

Join子句或WHERE子句中類(lèi)似col1 = col2形式的表達(dá)式中的數(shù)據(jù)列都是特別好的索引備選列。前面顯示的查詢(xún)中的col_b和col_c就是這樣的例子。如果MySQL能夠利用聯(lián)結(jié)列來(lái)優(yōu)化查詢(xún)，它一定會(huì)通過(guò)減少整表掃描來(lái)大幅度減少潛在的表－行組合。

考慮數(shù)據(jù)列的基數(shù)（cardinality）?；鶖?shù)是數(shù)據(jù)列所包含的不同值的數(shù)量。例如，某個(gè)數(shù)據(jù)列包含值1、3、7、4、7、3，那么它的基數(shù)就是4。索引的基數(shù)相對(duì)于數(shù)據(jù)表行數(shù)較高（也就是說(shuō)，列中包含很多不同的值，重復(fù)的值很少）的時(shí)候，它的工作效果最好。如果某數(shù)據(jù)列含有很多不同的年齡，索引會(huì)很快地分辨數(shù)據(jù)行。如果某個(gè)數(shù)據(jù)列用于記錄性別（只有”M”和”F”兩種值），那么索引的用處就不大。如果值出現(xiàn)的幾率幾乎相等，那么無(wú)論搜索哪個(gè)值都可能得到一半的數(shù)據(jù)行。在這些情況下，最好根本不要使用索引，因?yàn)椴樵?xún)優(yōu)化器發(fā)現(xiàn)某個(gè)值出現(xiàn)在表的數(shù)據(jù)行中的百分比很高的時(shí)候，它一般會(huì)忽略索引，進(jìn)行全表掃描。慣用的百分比界線(xiàn)是”30%”?，F(xiàn)在查詢(xún)優(yōu)化器更加復(fù)雜，把其它一些因素也考慮進(jìn)去了，因此這個(gè)百分比并不是MySQL決定選擇使用掃描還是索引的唯一因素。

索引較短的值。盡可能地使用較小的數(shù)據(jù)類(lèi)型。例如，如果MEDIUMINT足夠保存你需要存儲(chǔ)的值，就不要使用BIGINT數(shù)據(jù)列。如果你的值不會(huì)長(zhǎng)于25個(gè)字符，就不要使用CHAR(100)。較小的值通過(guò)幾個(gè)方面改善了索引的處理速度：

· 較短的值可以更快地進(jìn)行比較，因此索引的查找速度更快了。

· 較小的值導(dǎo)致較小的索引，需要更少的磁盤(pán)I/O。

· 使用較短的鍵值的時(shí)候，鍵緩存中的索引塊（block）可以保存更多的鍵值。MySQL可以在內(nèi)存中一次保持更多的鍵，在不需要從磁盤(pán)讀取額外的索引塊的情況下，提高鍵值定位的可能性。

對(duì)于InnoDB和BDB等使用聚簇索引（clustered index）的存儲(chǔ)引擎來(lái)說(shuō)，保持主鍵（primary key）短小的優(yōu)勢(shì)更突出。聚簇索引中數(shù)據(jù)行和主鍵值存儲(chǔ)在一起（聚簇在一起）。其它的索引都是次級(jí)索引；它們存儲(chǔ)主鍵值和次級(jí)索引值。次級(jí)索引屈從主鍵值，它們被用于定位數(shù)據(jù)行。這暗示主鍵值都被復(fù)制到每個(gè)次級(jí)索引中，因此如果主鍵值很長(zhǎng)，每個(gè)次級(jí)索引就需要更多的額外空間。

索引字符串值的前綴（prefixe）。如果你需要索引一個(gè)字符串?dāng)?shù)據(jù)列，那么最好在任何適當(dāng)?shù)那闆r下都應(yīng)該指定前綴長(zhǎng)度。例如，如果有CHAR(200)數(shù)據(jù)列，如果前面10個(gè)或20個(gè)字符都不同，就不要索引整個(gè)數(shù)據(jù)列。索引前面10個(gè)或20個(gè)字符會(huì)節(jié)省大量的空間，并且可能使你的查詢(xún)速度更快。通過(guò)索引較短的值，你可以獲得那些與比較速度和磁盤(pán)I/O節(jié)省相關(guān)的好處。當(dāng)然你也需要利用常識(shí)。僅僅索引某個(gè)數(shù)據(jù)列的第一個(gè)字符串可能用處不大，因?yàn)槿绻@樣操作，那么在索引中不會(huì)有太多的唯一值。

你可以索引CHAR、VARCHAR、BINARY、VARBINARY、BLOB和TEXT數(shù)據(jù)列的前綴。

使用最左（leftmost）前綴。建立多列復(fù)合索引的時(shí)候，你實(shí)際上建立了MySQL可以使用的多個(gè)索引。復(fù)合索引可以作為多個(gè)索引使用，因?yàn)樗饕凶钭筮叺牧屑隙伎梢杂糜谄ヅ鋽?shù)據(jù)行。這種列集合被稱(chēng)為”最左前綴”（它與索引某個(gè)列的前綴不同，那種索引把某個(gè)列的前面幾個(gè)字符作為索引值）。

假設(shè)你在表的state、city和zip數(shù)據(jù)列上建立了復(fù)合索引。索引中的數(shù)據(jù)行按照state/city/zip次序排列，因此它們也會(huì)自動(dòng)地按照state/city和state次序排列。這意味著，即使你在查詢(xún)中只指定了state值，或者指定state和city值，MySQL也可以使用這個(gè)索引。因此，這個(gè)索引可以被用于搜索如下所示的數(shù)據(jù)列組合：

state, city, zip state, city state

MySQL不能利用這個(gè)索引來(lái)搜索沒(méi)有包含在最左前綴的內(nèi)容。例如，如果你按照city或zip來(lái)搜索，就不會(huì)使用到這個(gè)索引。如果你搜索給定的state和具體的ZIP代碼（索引的1和3列），該索引也是不能用于這種組合值的，盡管MySQL可以利用索引來(lái)查找匹配的state從而縮小搜索的范圍。

不要過(guò)多地索引。不要認(rèn)為”索引越多，性能越高”，不要對(duì)每個(gè)數(shù)據(jù)列都進(jìn)行索引。我們?cè)谇懊嫣岬竭^(guò)，每個(gè)額外的索引都會(huì)花費(fèi)更多的磁盤(pán)空間，并降低寫(xiě)操作的性能。當(dāng)你修改表的內(nèi)容的時(shí)候，索引就必須被更新，甚至可能重新整理。如果你的索引很少使用或永不使用，你就沒(méi)有必要減小表的修改操作的速度。此外，為檢索操作生成執(zhí)行計(jì)劃的時(shí)候，MySQL會(huì)考慮索引。建立額外的索引會(huì)給查詢(xún)優(yōu)化器增加更多的工作量。如果索引太多，有可能（未必）出現(xiàn)MySQL選擇最優(yōu)索引失敗的情況。維護(hù)自己必須的索引可以幫助查詢(xún)優(yōu)化器來(lái)避免這類(lèi)錯(cuò)誤。

如果你考慮給已經(jīng)索引過(guò)的表添加索引，那么就要考慮你將增加的索引是否是已有的多列索引的最左前綴。如果是這樣的，不用增加索引，因?yàn)橐呀?jīng)有了（例如，如果你在state、city和zip上建立了索引，那么沒(méi)有必要再增加state的索引）。

讓索引類(lèi)型與你所執(zhí)行的比較的類(lèi)型相匹配。在你建立索引的時(shí)候，大多數(shù)存儲(chǔ)引擎會(huì)選擇它們將使用的索引實(shí)現(xiàn)。例如，InnoDB通常使用B樹(shù)索引。MySQL也使用B樹(shù)索引，它只在三維數(shù)據(jù)類(lèi)型上使用R樹(shù)索引。但是，MEMORY存儲(chǔ)引擎支持散列索引和B樹(shù)索引，并允許你選擇使用哪種索引。為了選擇索引類(lèi)型，需要考慮在索引數(shù)據(jù)列上將執(zhí)行的比較操作類(lèi)型：

· 對(duì)于散列（hash）索引，會(huì)在每個(gè)數(shù)據(jù)列值上應(yīng)用散列函數(shù)。生成的結(jié)果散列值存儲(chǔ)在索引中，并用于執(zhí)行查詢(xún)。散列函數(shù)實(shí)現(xiàn)的算法類(lèi)似于為不同的輸入值生成不同的散列值。使用散列值的好處是散列值比原始值的比較效率更高。散列索引用于執(zhí)行=或=操作等精確匹配的時(shí)候速度非?？?。但是對(duì)于查詢(xún)一個(gè)值的范圍效果就非常差了：

id 30 weight BETWEEN 100 AND 150

· B樹(shù)索引可以用于高效率地執(zhí)行精確的或者基于范圍（使用操作、=、=、=、、、!=和BETWEEN）的比較。B樹(shù)索引也可以用于LIKE模式匹配，前提是該模式以文字串而不是通配符開(kāi)頭。

如果你使用的MEMORY數(shù)據(jù)表只進(jìn)行精確值查詢(xún)，散列索引是很好的選擇。這是MEMORY表使用的默認(rèn)的索引類(lèi)型，因此你不需要特意指定。如果你希望在MEMORY表上執(zhí)行基于范圍的比較，應(yīng)該使用B樹(shù)索引。為了指定這種索引類(lèi)型，需要給索引定義添加USING BTREE。例如：

CREATE TABLE lookup ( id INT NOT NULL, name CHAR(20), PRIMARY KEY USING BTREE (id) ) ENGINE = MEMORY;

如果你希望執(zhí)行的語(yǔ)句的類(lèi)型允許，單個(gè)MEMORY表可以同時(shí)擁有散列索引和B樹(shù)索引，即使在同一個(gè)數(shù)據(jù)列上。

有些類(lèi)型的比較不能使用索引。如果你只是通過(guò)把值傳遞到函數(shù)（例如STRCMP()）中來(lái)執(zhí)行比較操作，那么對(duì)它進(jìn)行索引就沒(méi)有價(jià)值。服務(wù)器必須計(jì)算出每個(gè)數(shù)據(jù)行的函數(shù)值，它會(huì)排除數(shù)據(jù)列上索引的使用。

使用慢查詢(xún)（slow-query）日志來(lái)識(shí)別執(zhí)行情況較差的查詢(xún)。這個(gè)日志可以幫助你找出從索引中受益的查詢(xún)。你可以直接查看日志（它是文本文件），或者使用mysqldumpslow工具來(lái)統(tǒng)計(jì)它的內(nèi)容。如果某個(gè)給定的查詢(xún)多次出現(xiàn)在”慢查詢(xún)”日志中，這就是一個(gè)線(xiàn)索，某個(gè)查詢(xún)可能沒(méi)有優(yōu)化編寫(xiě)。你可以重新編寫(xiě)它，使它運(yùn)行得更快。你要記住，在評(píng)估”慢查詢(xún)”日志的時(shí)候，”慢”是根據(jù)實(shí)際時(shí)間測(cè)定的，在負(fù)載較大的服務(wù)器上”慢查詢(xún)”日志中出現(xiàn)的查詢(xún)會(huì)多一些。

*4.建索引的幾大原則*

4.1.最左前綴匹配原則，非常重要的原則，mysql會(huì)一直向右匹配直到遇到范圍查詢(xún)(、、between、like)就停止匹配，比如a = 1 and b = 2 and c 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調(diào)整。

4.2.=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢(xún)優(yōu)化器會(huì)幫你優(yōu)化成索引可以識(shí)別的形式

4.3.盡量選擇區(qū)分度高的列作為索引,區(qū)分度的公式是count(distinct col)/count(*)，表示字段不重復(fù)的比例，比例越大我們掃描的記錄數(shù)越少，唯一鍵的區(qū)分度是1，而一些狀態(tài)、性別字段可能在大數(shù)據(jù)面前區(qū)分度就是0，那可能有人會(huì)問(wèn)，這個(gè)比例有什么經(jīng)驗(yàn)值嗎？使用場(chǎng)景不同，這個(gè)值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄

4.4.索引列不能參與計(jì)算，保持列“干凈”，比如from_unixtime(create_time) = '2014-05-29'就不能使用到索引，原因很簡(jiǎn)單，b+樹(shù)中存的都是數(shù)據(jù)表中的字段值，但進(jìn)行檢索時(shí)，需要把所有元素都應(yīng)用函數(shù)才能比較，顯然成本太大。所以語(yǔ)句應(yīng)該寫(xiě)成create_time = unix_timestamp('2014-05-29');

4.5.盡量的擴(kuò)展索引，不要新建索引。比如表中已經(jīng)有a的索引，現(xiàn)在要加(a,b)的索引，那么只需要修改原來(lái)的索引即可。

我需要用Mysql建一個(gè)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)里存放選擇題判斷題之類(lèi)的數(shù)據(jù)，

數(shù)據(jù)庫(kù)不需要導(dǎo)入，可以讓Android跟服務(wù)器接口站對(duì)接，接口站直接連接mysql。

軟件的話(huà)，Navicat蠻好用的

文章標(biāo)題：mysql怎么存題目,MySQL數(shù)據(jù)庫(kù)題目
網(wǎng)站URL：http://aaarwkj.com/article32/dsigisc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、云服務(wù)器、自適應(yīng)網(wǎng)站、App設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)公司、手機(jī)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)