計算機的內存編號是從零開始編號的，是壹種規定。出現這個錯誤，可能是妳的代碼執行過程種，索引為負值。
1、索引的定義
在關系數據庫中，索引是壹種單獨的、物理的對數據庫表中壹列或多列的值進行排序的壹種存儲結構，它是某個表中壹列或若幹列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單。索引的作用相當於圖書的目錄，可以根據目錄中的頁碼快速找到所需的內容。
索引提供指向存儲在表的指定列中的數據值的指針，然後根據您指定的排序順序對這些指針排序。數據庫使用索引以找到特定值，然後順指針找到包含該值的行。這樣可以使對應於表的SQL語句執行得更快，可快速訪問數據庫表中的特定信息。
當表中有大量記錄時，若要對表進行查詢，第壹種搜索信息方式是全表搜索，是將所有記錄壹壹取出，和查詢條件進行壹壹對比，然後返回滿足條件的記錄，這樣做會消耗大量數據庫系統時間，並造成大量磁盤I/O操作；第二種就是在表中建立索引，然後在索引中找到符合查詢條件的索引值，最後通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。
2、索引原理
除了詞典，生活中隨處可見索引的例子，如火車站的車次表、圖書的目錄等。它們的原理都是壹樣的，通過不斷的縮小想要獲得數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是我們總是通過同壹種查找方式來鎖定數據。
數據庫也是壹樣，但顯然要復雜許多，因為不僅面臨著等值查詢，還有範圍查詢(>、<、between、in)、模糊查詢(like)、並集查詢(or)等等。數據庫應該選擇怎麽樣的方式來應對所有的問題呢？我們回想字典的例子，能不能把數據分成段，然後分段查詢呢？最簡單的如果1000條數據，1到100分成第壹段，101到200分成第二段，201到300分成第三段……這樣查第250條數據，只要找第三段就可以了，壹下子去除了90%的無效數據。但如果是1千萬的記錄呢，分成幾段比較好？稍有算法基礎的同學會想到搜索樹，其平均復雜度是lgN，具有不錯的查詢性能。但這裏我們忽略了壹個關鍵的問題，復雜度模型是基於每次相同的操作成本來考慮的，數據庫實現比較復雜，數據保存在磁盤上，而為了提高性能，每次又可以把部分數據讀入內存來計算，因為我們知道訪問磁盤的成本大概是訪問內存的十萬倍左右，所以簡單的搜索樹難以滿足復雜的應用場景。
3、索引的數據結構
前面講了生活中索引的例子，索引的基本原理，數據庫的復雜性，又講了操作系統的相關知識，目的就是讓大家了解，任何壹種數據結構都不是憑空產生的，壹定會有它的背景和使用場景，我們現在總結壹下，我們需要這種數據結構能夠做些什麽，其實很簡單，那就是：每次查找數據時把磁盤IO次數控制在壹個很小的數量級，最好是常數數量級。那麽我們就想到如果壹個高度可控的多路搜索樹是否能滿足需求呢？就這樣，b+樹應運而生。
如上圖，是壹顆b+樹，關於b+樹的定義可以參見B+樹，這裏只說壹些重點，淺藍色的塊我們稱之為壹個磁盤塊，可以看到每個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P1、P2、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項，如17、35並不真實存在於數據表中。