一、“N叉樹”的N值在MySQL中是可以被人工調整嗎？
1， 通過改變key值來調整
N叉樹中非葉子節點存放的是索引信息，索引包含Key和Point指針。Point指針固定為6個字節，假如Key為10個字節，那么單個索引就是16個字節。如果B+樹中頁大小為16K，那么一個頁就可以存儲1024個索引，此時N就等於1024。我們通過改變Key的大小，就可以改變N的值
2， 改變頁的大小
頁越大，一頁存放的索引就越多，N就越大。
數據頁調整后，如果數據頁太小層數會太深，數據頁太大，加載到內存的時間和單個數據頁查詢時間會提高，需要達到平衡才行。
二、一個innoDB引擎的表，數據量非常大，根據二級索引搜索會比主鍵搜索快，文章闡述的原因是主鍵索引和數據行在一起，非常大搜索慢，我的疑惑是：通過普通索引找到主鍵ID后，同樣要跑一邊主鍵索引？
覆蓋索引。
三、
如果你要重建索引 k，你的兩個 SQL 語句可以這么寫：
alter table T drop index k;
alter table T add index(k);
如果你要重建主鍵索引，也可以這么寫：
alter table T drop primary key;
alter table T add primary key(id);
我的問題是，對於上面這兩個重建索引的作法，說出你的理解。如果有不合適的，為什么，更好的方法是什么？
索引可能因為刪除，或者頁分裂等原因，導致數據頁有空洞，重建索引的過程會創建一個新的索引，把數據按順序插入，這樣頁面的利用率最高，也就是索引更緊湊、更省空間。
數據空洞其實存儲就浪費了。
刪除數據的時候,當前刪除索引被標記為被刪除,改索引位置則可以被空間復用,當一頁數據都被刪除時頁可以被復用,空間被復用但是磁盤系統表空間是未改變的,需要通過重建表,重建表的邏輯對數據緊湊排列來保存到臨時文件中也就是online的邏輯對server端來說就是inplace邏輯
重建索引 k 的做法是合理的，可以達到省空間的目的。但是，重建主鍵的過程不合理。不論是刪除主鍵還是創建主鍵，都會將整個表重建。所以連着執行這兩個語句的話，第一個語句就白做了。這兩個語句，你可以用這個語句代替 ： alter table T engine=InnoDB
四、
簡單說一下我對你這個幾種情況的理解：
1.SELECT * FROM test_like WHERE uname LIKE 'j'/ 'j%' / '%j'/ '%j%'用到uname的普通索引
A：這個應該是走到覆蓋索引的緣故；
2.添加一個age字段
like后面的'%j'/ '%j%' 這兩種情況用不到索引
把select * 改為 select id / select uname / select id,uname
like后面'j'/ 'j%' / '%j'/ '%j%' 這四種情況又都可以用到uname普通索引
A：如果返回值只包含（id，uname）的話，覆蓋索引就能拿到所有數據，所以這種情況下like后面的多種條件都可以走到普通索引。但是如果select * 的話，返回數據由於包含了age字段，而age字段在uname的覆蓋索引中查詢不到需要二次回表，因此便走不到索引。
3.建立uname,age的聯合索引
模糊查詢還是 LIKE 'j'/ 'j%' / '%j'/ '%j%'四種情況
其中select id / select uname / select id,uname
會用到uname的普通索引
select * 會用到uname,age的組合索引
A：如果返回值只包含（id，uname）的話，覆蓋索引就能拿到所有數據，所以這種情況下like后面的多種條件都可以走到普通索引。如果查詢條件變為selec * 的話聯合索引在這時候就是最優的覆蓋索引了，所以走到了聯合索引。
五、只要用戶定義的索引字段中包含了主鍵中的字段，那么這個字段就不會再被InnoDB自動加到索引中了，如果用戶的索引字段中沒有完全包含主鍵字段，InnoDB就會把剩下的主鍵字段加到索引末尾。
六、innodb行級鎖是通過鎖索引記錄實現的。如果update的列沒建索引，即使只update一條記錄也會鎖定整張表嗎？比如update t set t.name='abc' where t.name='cde'; name字段無索引
是的。但是你可以再往前考慮一下，如果是 你的update 語句后面加個limit 1, 會怎么鎖？
1.可以自己實踐一下,當加上limit1之后 更新語句的執行流程是先去查詢再去更新,也就是查詢sql為 select * from t where name = "abc" limit 1 for update,相當於掃描主鍵索引找到第一個滿足name="abc"的條件為止,此時鎖的區間為(負無窮,當前行的id],如果在這個id之后的更新和插入時都不會鎖住的,在這個id之前的更新和插入會阻塞,之后則不會阻塞
2.如果不加limit 1的話,因為此時是整個主鍵索引全表掃描則整個表鎖住了
3.你說的回表的行鎖,比如字段name有普通索引,在更新操作時普通索引會鎖住的同時,如果更新操作需要回表的話對應的主鍵索引也會存在鎖(主鍵索引鎖臨界鎖會退化為行鎖),普通索引(間隙鎖和行鎖)