一 問(wèn)題層面
先從今天在項(xiàng)目當(dāng)中遇到的一個(gè)問(wèn)題開始：
項(xiàng)目采用的flask_sqlalchemy ,因?yàn)樾枨蟮脑虬Ｒ牵趍odel層加了一個(gè)包含兩個(gè)field的uniqueConstrain,在數(shù)據(jù)庫(kù)間庫(kù)的時(shí)候遇到了一個(gè)問(wèn)題：
Specified Key was too long:max key length is 767 bytes
翻譯就是 個(gè)別field太長(zhǎng)了，超過(guò)了767byte的限制
二 原因?qū)用?br>
1
之前普通field從未報(bào)過(guò)此種錯(cuò)誤损合，原因肯定是加了uc,眾所周知，加了uc是有索引的娘纷，因?yàn)樯婕傲怂饕?br>
2
inodb對(duì)索引長(zhǎng)度是有限制的嫁审，但是限制長(zhǎng)度是255字節(jié)啊，為什么還是報(bào)錯(cuò)了赖晶？
"Prefixes can be up to 255 bytes long (or 1000 bytes for MyISAM and InnoDB tables as of MySQL
4.1.2). Note that prefix limits are measured in bytes, whereas the prefix length in CREATE INDEX
statements is interpreted as number of characters. Take this into account when specifying a
prefix length for a column that uses a multi-byte character set."
3
uc的索引長(zhǎng)度應(yīng)該是創(chuàng)建UC的field長(zhǎng)度之和
三 原理層面
那么為什么索引要加一個(gè)最長(zhǎng)字符的限制呢律适，從索引的實(shí)現(xiàn)層面來(lái)講，不管多長(zhǎng)的索引按理我都可以排序放到Ｂ/B+_樹中遏插？
十分費(fèi)解
