別於查詢條件以primary key / 主索引的欄位，想要在同一個row裡面，以其他欄位作為查詢條件，可以為其設index，又稱secondary index / 次索引。

這種secondary index的設置對象必定是非primary key的欄位專用，兩種column涇渭分明。

CASSANDRA/SCYLLA 所謂的index，其實跟RDBMS裡面的index概念上有一點類似，不過CASSANDRA/SCYLLA的欄位格式能設置index的選擇可多了，除了基本型態以外，set、list、map格式的欄位都能拿來設置index，實務上是不是真的有人這樣設，身為新手的筆者就不是那麼清楚了。

其中map會稍微特殊一點，因為map本身有key和value兩個部分，可以挑一個來設置index，無法同時對key和value都建次索引。

認真要了解次索引，請先拋開原本在RDBMS裡面學到的index概念，因為我們東西都在分散式系統了。

primary key關係著分區的策略，所以查詢條件用到了primary key，那麼系統就知道它放到哪個node，如此一來查詢速度是可以很迅速。

再複習一次，由於CASSANDRA/SCYLLA藉由partition key將資料做分區，分區的資料勢必會跨節點儲存。

而每個節點，必須要負責每個分區的次索引，所以如果使用次索引做查詢，會牽扯到許多節點導致成本昂貴。

從整個系統層面來看，每個node的資料怎麼放，已經被primary key內的partition key所決定了，secondary index到底是在做什麼呢？其實就是有一張隱藏的表，紀錄每個secondary index所對應的primary key，從secondary index找到該row隸屬的primary key，再拿來做查詢。

 CREATE TABLE student (    
    id int,    
    name string,    
    grade int,       
    PRIMARY KEY (id));
)

CREATE INDEX grade ON student( grade );

假設資料是這樣子：

那個secondary index存放的內容，長相大概是這樣子：

因此，如果查詢條件未使用到primary key，只有secondary index作為搜尋條件，那麼這個查詢很有可能就需要多個節點合作。

CASSANDRA/SCYLLA在官方的說明，大意是說ALLOW FILTERING或者secondary index可能在某些狀況使用上算ok，但是未必有最好的查詢效益，建議是可以用view來替代，後續我們會有一篇專來討論view的部分。