我是第一次探索数据仓库的DB新手。我已经完成了将大量数据从我们的一个生产系统 (MS SQL Server 2012( 复制到我们的数据仓库 (MySQL( 的过程。
我遇到的问题是，我可用于 ETL 过程的软件/硬件资源不够强大，无法使用单个查询复制较大表中的所有数据(程序会耗尽内存并崩溃(。为了解决这个问题，我通过在表 id 上使用取模运算符添加一个 where 子句将这些表分成 12 个块，因为这既快速又容易编写：
SELECT * FROM table WHERE table.tableID % 12 = 0;
SELECT * FROM table WHERE table.tableID % 12 = 1;
SELECT * FROM table WHERE table.tableID % 12 = 2;
etc.
我现在想知道的是，这是否会影响我的数据仓库相对于原始数据库的性能。在旧数据库中，数据大致按时间顺序插入，显然新数据仓库并非如此。
我对数据库引擎实际存储数据的方式了解不够，无法知道这是否是一个问题。我在数据仓库上拥有与原始表上相同的索引，但我不知道数据库引擎是否真的会根据索引重新排列内存中的数据以使读取速度更快。
我是否因为以这种方式复制和插入数据而陷入困境？
这可能不会有什么不同。 数据库通常只能在声明聚集索引(某种类型(时利用表中的排序。 如果您声明了一个，则无论广告顺序如何，数据都将在数据页上排序。 如果没有，则优化程序无法利用排序。
有一些类型的查询(特别是exists(，其性能可能会受到读取数据时数据到达的实际顺序的影响。 但这并不常见。 如果表不适合内存，并且您依赖于位于同一位置的类似数据来提高性能，则性能也可能很差。 这通常是一个糟糕的假设，但它可能是某些查询的基础。
在某些情况下，数据排序可能会产生看似正确的结果，但这些是"糟糕的"SQL：
- 没有
ORDER BY子句但期望结果以特定顺序表示的查询。 - 使用 MySQL mis(功能( 的查询，该查询允许聚合查询
SELECT中的非聚合、非键列。 - 依赖于没有
ORDER BY子句的GROUP_CONCAT()中值的顺序的查询。
这些是"坏的"，因为它们依赖于观察到的系统行为，而不是记录的行为(毫无疑问，我可能错过了一些(。
当然，您可以测试您的新系统以查看是否是这种情况。 但是先验地，插入的顺序不是我首先关心的问题。
如果你有相同的索引，数据将或多或少地以相同的方式存储，假设你在一列上有一个哈希索引，这种结构的实现在MySql DB和MySql服务器中将是相似的。问题是 oltp 工作负载与 olap 工作负载不同，因此 oltp 的良好索引对于数据仓库来说仍然不是好的索引，但它取决于您的数据。查看本文以更好地了解 oltp 和 olap 的区别：oltp 与 olap。试着考虑如何减少表基数，假设在你的oltp系统中，你存储了有关销售的信息，你有这样的东西：
| DateTime | Product | QTY |
| ---------------- | --------|-----|
| 2018-03-05 10:50 | prod1 | 5 |
包含 10^8 条记录的表。也许您只想在一个日期中存储产品数量，如下所示：
| Date | Qty |
|------------|-------------|
| 2018-03-05 | 10000 |
这将减少表的基数，并提高应用程序的效率