mysql删索引

MySQL当中如何删除某个字段的唯一索引或者修改该字段的唯一索引为普通索引

调整唯一索引： ALTER TABLE table_name MODIFY columns_name data_type(x);
删除唯一索引： DROP INDEX index_name ON table_name;
转换为普通索引：首先执行 DROP INDEX index_name ON table_name;然后执行 CREATE INDEX index_name ON table_name(column_name);
备份数据。

数据库，逻辑删还是物理删？

说实话，在数据库操作中选择逻辑删除和物理删除是我当时遇到的一个陷阱。
现在想想，我觉得有必要具体问题具体分析。
首先，我们来谈谈定义。
这个问题至少可以说很复杂，但是有两件事可以说很简单。

逻辑删除，说白了就是给数据加一个标记，比如创建一个is_deleted字段，只有删除的时候才改变值。
比如我们做ERP系统的时候，我们的客户使用的是逻辑删除，特别是担心删除订单数据后出现问题。
物理删除是指实际删除。
一旦删除，它就会消失。
你想恢复吗？灾难！我有一个朋友，在金融行业工作。
在特定的测试环境中，我不小心物理删除了一条关键记录。
使用binlog恢复花了整整4 8 个小时，几乎存在合规风险。

有趣的是，逻辑删除确实有利于安全。
我记得有一个电子商务客户在半夜按了错误的命令来清理库存表。
他之前使用的逻辑删除解决了这个问题。
如果真的被物理删除，损失将是巨大的。
但这也是有代价的。
数据很多，标记为“已删除”的数据占用了实际空间。
我有一个项目表，有几千万条数据。
逻辑删除的记录堆积起来，确实降低了查询性能。

但是物理删除也有其好处。
例如，如果您正在创建用户行为日志，则每条记录可能只有几 KB，删除它也不会感到难过。
我之前接手了一个旧项目。
物理删除日志表后，节省了一半的空间。
DBA还请了我一顿饭以示谢意。
当然，这种工作应该由专人来完成。
编写脚本后，您必须手动检查它。
不能像逻辑删除那样任意更改。

解决唯一性问题特别有趣。
我见过的最荒谬的事情是在 is_deleted 字段上添加连接索引，然后在删除记录时将 is_deleted 更改为 NULL。
不过，这是有前提的，取决于你的数据库系统如何处理唯一索引中NULL值的逻辑。
例如，PostgreSQL 和 MySQL 是不同的，因此您必须实际运行它们才能看到它们。
还有一些使用软删除时间的解决方案，例如在订单表中添加一个delete_at字段，并在删除时更新该时间，然后与订单号形成唯一索引。
这样做的优点是逻辑更清晰，缺点是更新索引比更改 is_deleted 字段更耗费性能。

关于该项目的规模，没有记录的经验。
比如我们在做CRM系统的时候，有一个客户说“删了就死”，就用了逻辑删除。
但是有乙方，帮你写小程序。
该系统上有少量数据，但存在大量物理删除。
数据的价值尤为重要。
例如，如果用户的收费记录被物理删除，某些游戏公司必须支付巨额赔偿。
因此我们自己使这些类型的表在物理上不可删除。
但如果删除的话，这样的“外卖订单记录”也会被删除。
没必要太严肃。

现在想想，最重要的其实是运维成本。
逻辑删除系统需要存储每个备份的“已删除”数据，并知道在恢复期间保留什么和丢弃什么。
DBA差点被骂，因为系统升级时没有清理逻辑删除数据，最终备份文件大了一倍。
对于物理删除的系统，备份要容易得多，但恢复是一项技术任务。

最终这个问题没有标准答案。
想一想。
您的客户想要数据安全还是系统性能？操作和维护比易用性或数据完整性更重要吗？有时技术选型就是一个在矛盾之间寻找妥协的过程。
我目前的做法是从逻辑上完全删除核心数据并适当处理边缘数据。
无论如何，还没有一个项目被逻辑删除推翻过。