你好拉尔斯，

谢谢，明白了：

-按天划分的日期格式为YYYYMMDD。
-上面的TO_DATE旨在使DAY格式在语义上正确。

"按天计算"设计旨在最大程度地提高海量数据的性能，
最后应如下所示：

-我想，通过说服解析器/执行计划直接放入某个分区，可以使按日访问的性能最佳。

-一个HANA分区密钥或为我的CALENDAR_TIME添加的任何内容
-批量数据的联接超过了分区密钥。

这将需要：

---->一个HANA SQL SELECT关键字（例如Oracle中的PARTITION）
精确地放入某个分区或还有其他方法吗？
（不能在保留字-SAP帮助门户）

-一种识别分区密钥的方法，例如。 从系统视图中查看

两者都有办法吗？

谢谢！

最良好的祝愿

马丁

嗨，马丁，介意选择我的答案作为解决这个问题的最好方法吗？

我为您提供帮助只是出于礼貌。

赞赏。

分区定义语法不是太灵活。

如果输入这样的日期范围

更改表mypart
 按范围划分（ydate）
 （部分'20190101'<=值<'20200101'，
 分区'20200101'<=值<'20210101'，
 分区其他）；
 

它起作用。

但是不知道为什么"'DD.MM.YYYY'"应该是原始代码中的上限。

关于 最基本的分区-如果您想按年份分区，我建议使用YEAR（）函数进行分区。 这样可以更轻松地指定分区。

更改表mypart
 按范围划分（年（ydate））
 （PARTITION值= 2019，
 分区值= 2020，
 分区其他）；
 

这里的日期时间格式没有问题。

是的，我完全了解PARTITION子句，只是无法理解您的意思 通过"。 .. drop到特定分区... "。

" 是否可以从特定分区读取？"

现在，此选项的目的不是调整性能，而是提供（相对）低级控制来读取数据的选项。

一个例子是 从表中提取数据，该表中并非所有分区都可以一起加载，或者一个分区根本不可读（例如由于数据损坏）。

作为调整机制，这是垃圾。

当一行DBA决定对表进行重新分区时，您将做什么？ 重写所有的SQL代码吗？

看看您的测试用例-您正在比较数十毫秒的差异来查看单个执行。

并且在分区修剪优化过程中，运行时不会随数据量扩展，因此很容易在误差范围内。 两种执行计划都表明，数据是从相同的分区中获取的。

有效地，您将动态和自动分区修剪交换为某些东西，只要以最小的方式更改了分区方案，该东西就会立即中断（ 并可能产生错误的结果集，因为没人会意识到这一点-不会出现错误消息！），并节省了20毫秒的准备时间...不是一个很好的交换。