用对 CS_ / RS_：看懂 SAP HANA 执行引擎选择，写出更稳更快的 SQL
在 SAP HANA 里做性能优化，很多人会把注意力放在一条条 SQL 的改写、索引、分区、参数调优上，但真正影响执行效率的，还有一个更底层的关键点：这条语句最终由哪类执行引擎来完成。你在日志、Trace、Explain Plan、Plan Visualizer 里看到的CS_、RS_，正是理解这件事的入口。
不少项目里，开发同学会尝试用CS_JOIN、NO_CS_JOIN之类的 hint 去“指定”引擎，结果发现同一条语句在不同数据量、不同版本、不同环境下行为并不一致：有时确实走了列引擎，有时看起来又像走了别的路径。要把这类现象讲清楚，得把CS_ / RS_的语义、优化器的成本模型、以及如何以“最终执行计划”为准来验证，连成一条闭环。
CS_ / RS_ 到底在表达什么
CS和RS的含义非常直观：
CS：Column Store，列存相关的语义RS：Row Store，行存相关的语义
在 SAP HANA 的世界里，这不仅仅是表的存储格式差异。SAP HANA 同时支持列存表与行存表，并且整体以列存为默认与优势方向；官方文档也明确说明，SAP HANA 支持 column-wise（列式）与 row-wise（行式）两类表，并且对列式存储做了重点优化，列存是默认类型。(