在Oracle中，索引有啥优点和缺点？

Posted 2023-05-16

参考技术A 一：索引是什么：

通俗的来讲，索引在表中的作用，相当于书的目录对书的作用。索引与表一样，也属于段的一种。里面存放了用户的数据，跟表一样需要占用磁盘空间。索引是一种允许直接访问数据表中某一数据行的树型结构，为了提高查询效率而引入，是一个独立于表的对象，可以存放在与表不同的表空间中。索引记录中存有索引关键字和指向表中数据的指针（地址）。对索引进行的I/O操作比对表进行操作要少很多。索引一旦被建立就将被Oracle系统自动维护，查询语句中不用指定使用哪个索引。

二：优点：

①可以加快数据的检索速度。

②可以加速表和表之间的连接。

③使用分组和排序子句进行数据检索时,可以减少查询中分组和排序的时间。

三：缺点：

①创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

②索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间。

③当对表中的数据进行增加、删除和修改的时候，索引需要动态的维护，这样就降低了数据的维护速度。

   

Binary Log 在 MYSQL 数据流中的可用性：有啥缺点和优点？

【中文标题】Binary Log 在 MYSQL 数据流中的可用性：有啥缺点和优点？

【英文标题】：Usability of Binary Log in data streaming in MYSQL: What are the drawbacks and advantages?Binary Log 在 MYSQL 数据流中的可用性：有什么缺点和优点？

【发布时间】：2021-04-13 03:57:56

【问题描述】：

我一直在尝试使用 Kafka 连接从 MySQL 中读取数据，使用 MySQL 源连接器用于数据库和 debezium 连接器用于 bin 日志。我试图了解什么是提取更改数据的更好方法。 Bin 日志有写入日志等的开销，而从数据库读取有查询数据库的开销。与这两种方法相关的其他主要优点和缺点是什么？捕获变更数据的更好方法是什么？同样从 MySQL 8 开始，bin 日志默认启用。这是否意味着它可能是一种更好的做事方式？

【参考方案1】：

这个问题可以总结如下：

基于日志的 CDC（由 Debezium Connector 表示）与 基于轮询的 CDC（由 JDBC Source Connector 表示）的优缺点是什么？

基于查询的 CDC：

✓ 通常更容易设置 ✓ 需要更少的权限 ✗ 轮询数据库的影响 ✗ 需要源架构中的特定列来跟踪更改 ✗ 无法跟踪删除 ✗ 无法在轮询间隔之间跟踪多个事件

基于日志的 CDC：

✓ 捕获所有数据更改 ✓ 事件延迟低，同时避免增加 CPU 负载 ✓ 对数据模型没有影响 ✓ 可以捕获删除 ✓ 可以捕获旧记录状态和更多元数据 ✗ 更多设置步骤 ✗ 需要更高的系统权限 ✗ 对于某些专有数据库来说可能很昂贵

参考：

Five Advantages of Log-Based Change Data Capture 来自 Gunnar 莫林 No More Silos: How to Integrate Your Databases with Apache Kafka and CDC 罗宾·莫法特 堆栈溢出：Kafka Connect JDBC vs Debezium CDC

【讨论】：

你能给出一些专有数据库的名称吗？我也开始了解到默认情况下启用了 MySQL 8 日志箱。这是否意味着日志箱至少在某些方面变得不那么重了？

对于基于查询的 CDC，当您说无法在轮询间隔之间跟踪多个事件时，您是什么意思？

【参考方案2】：

@Iskuskov Alexander 给出的列表很棒。我再补充几点：

基于日志的 CDC 还需要写入日志（您在问题中提到了这一点）。这不仅会增加性能开销，还会增加存储空间。

基于日志的 CDC 需要连续的日志流。如果 CDC 遗漏了一个日志，那么副本就无法保持同步，整个副本必须由数据库的新快照初始化的新副本替换。

如果您的 CDC 定期离线，这意味着您需要保留日志直到 CDC 运行，而这很难预测会持续多长时间。这导致需要更多的存储空间。

也就是说，基于查询的 CDC 有其自身的缺点。在我的公司，我们使用了基于查询的 CDC，但我们发现它不方便，我们正在努力将其替换为基于 Debezium 日志的解决方案。由于其他答案中的许多原因，还有：

基于查询的 CDC 难以使架构更改与副本保持同步，因此如果源数据库中发生架构更改，可能需要将副本删除并替换为新快照。

副本经常处于“重建”状态数小时，此时它需要从快照重新初始化，而用户不喜欢这种停机时间。快照传输也增加了网络带宽需求。

没有一个解决方案比另一个“更好”。两者都有优点和缺点。作为工程师，您的工作是选择最适合您项目要求的选项。换句话说，选择对您的需求不利的最不坏的那个。

我们无法为您做出这样的选择，因为您比我们更了解您的项目。

---

你的cmets：

启用二进制日志不会产生读取查询的开销，但会产生大量写入查询的开销。根据 Percona 首席技术官 Vadim Tkachenko 的测量，MySQL 8.0 的开销变得更大，并在此报告：https://www.percona.com/blog/2018/05/04/how-binary-logs-affect-mysql-8-0-performance/

他得出结论，二进制日志的开销在 MySQL 5.7 中约为 13%，在 MySQL 8.0 中高达 30%。

您能否解释一下“副本经常处于“重建”状态数小时，此时需要从快照重新初始化”？你的意思是建立一个复制数据库？

是的，如果您需要构建新副本，您需要获取源数据库的快照并将其导入到副本中。每一步都需要时间：

创建源快照 将快照传输到副本所在的主机 将快照导入副本实例

多长时间取决于数据库的大小，但可以是几小时甚至天。在等待这个的时候，用户不能使用副本数据库，至少如果他们希望他们的查询分析源数据的完整副本的话。他们必须等待导入完成。

【讨论】：

感谢比尔的精彩解释。如果你曾经经历过，我只想知道还有什么事情。 Bin Logs 对数据库的吞吐量和延迟的影响程度如何。它会减慢整个数据库的速度吗？存储是一个方面，但性能是我担心的问题。

您能否解释一下“副本经常处于“重建”状态数小时，需要从快照重新初始化”？你的意思是建立一个复制数据库？