1. 动手前的准备：理解数据库操作的最小闭环
这些年带过不少新人，也帮同事排查过线上事故，发现大家对数据库的理解经常卡在一个错位的地方。很多人一上来就问“怎么建库”，但真正干活的时候，第一关不是SQL语法，而是搞清楚“你要操作的数据库”到底是什么。
先聊个最常见的误区。数据库这个词其实有三层含义：第一层是数据库服务本身，比如你装好的MySQL实例、PostgreSQL实例；第二层是服务里面的逻辑存储单元，也就是我们常说“创建数据库”的那个database；第三层是数据表。本文要讲的创建、查看、选择、删除，全部针对第二层逻辑存储单元。如果你没分清这三层，很容易出现这样的情况——在MySQL里敲CREATE DATABASE成功后，用可视化工具却找不到表，实际上你只是建了一个空的库，表根本还没建。
另外，动手之前一定要确认权限。创建和删除数据库属于高风险操作，MySQL里对应的是CREATE权限和DROP权限，一般由管理员账号持有。如果你在团队里使用的是普通开发账号，大概率会收到“Access denied for user”的报错。这个报错不是环境问题，大概率是权限不够，别纠结半天改配置。
操作环境方面，建议至少准备一个本地的MySQL或PostgreSQL实例，也可以直接用Docker起一个测试容器。我平时最常用的还是命令行客户端，因为很多脚本化、自动化场景根本离不开命令行操作，而且命令行能更清晰地暴露字符集、权限这类隐藏问题。
下面所有示例以MySQL 8.x为主，需要的话我会顺手标注PostgreSQL的差异点。你跟着敲一遍，基本就能把“创建、查看、选择、删除”这个闭环跑通了。这个闭环的熟练程度，直接决定了你后面写脚本、做数据迁移、搞自动化运维时是否顺手——因为任何上层工具，底层都逃不开这几条SQL。
2. 创建数据库：核心语法、字符集与排序规则的坑
2.1 最简单的创建语句，但别急着敲回车
创建数据库的标准语法是：
CREATE DATABASE 数据库名;看起来简单，对不对？但这个语句在真实环境里几乎不会裸奔着用。原因在于数据库的默认配置太“随机”了，尤其在字符集和排序规则这两个参数上。
MySQL 8.0默认字符集是utf8mb4，这已经是比较合理的默认值了，但你若用的是PostgreSQL或者更老的MySQL 5.7，默认字符集可能是latin1——这意味着中文可能存不进去，或者存进去了查不出来。
所以更稳妥的写法是：
CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;这里的IF NOT EXISTS作用很直白：如果库已经存在就不报错，适合脚本里反复执行。CHARACTER SET指定字符集，COLLATE指定排序规则。排序规则决定了字段比较和排序时的行为，比如大小写是否敏感、中文拼音排序方式等。
选utf8mb4是因为它能完整支持中文、emoji以及各种特殊符号。utf8mb4_0900_ai_ci是MySQL 8.0下的默认排序规则，大小写不敏感，基本够用。如果你在建库时偷懒不指定，后面迁移数据或者同步工具做字符集校验时会非常痛苦——我见过太多因为字符集不一致导致的乱码和数据同步中断，排查一圈下来，问题根源往往就是最初建库时少写了两个参数。
2.2 眼中不要只有“建库”，还要看建库后的实体状态
创建完数据库之后，推荐你立刻执行一条验证语句：
SHOW CREATE DATABASE mydb;这条命令会显示建库时的完整语句，包括字符集和排序规则。它能帮你确认参数是否真正生效，也能作为后续重建数据库的备份依据。很多人在建库之后从来不回头确认，结果过了一段时间才发现字符集根本不是自己想要的，那时候表都建完了，改起来成本极高。
PostgreSQL下的做法稍有不同，它的默认字符集通常跟随模板数据库template1，所以建库时最好显式指定编码：
CREATE DATABASE mydb ENCODING 'UTF8' LC_COLLATE 'zh_CN.utf8' LC_CTYPE 'zh_CN.utf8' TEMPLATE template0;这里有个小原因：如果TEMPLATE不指定template0，而是沿用默认的template1，某些系统上会报“invalid locale name”之类的错。指定template0可以绕开模板库中已有的collation限制。
2.3 命名的规范：为什么别用驼峰和中文
数据库命名这件事，平时不太有人专门提醒，但踩坑率极高。我的建议只有三条：
第一，全小写加下划线，比如order_db、user_center。MySQL在Linux下对表名和库名是大小写敏感的，而在Windows下不敏感，这种平台差异导致的“开发环境正常、生产环境表找不到”问题，我用五年经验告诉你，遇上一次就够你失眠两周。
第二，不要用中文库名。虽然MySQL支持中文库名，但你后面写Shell脚本、Java连接串、Python ORM映射时，中文编码问题会像幽灵一样缠绕着你，迟早要还债。
第三，不要用保留字做库名，比如order、group、select。如果非得用不可，请务必用反引号包裹，但这只是自找麻烦，建议直接换名。
3. 查看数据库：别只盯着SHOW DATABASES
3.1 基础查看与当前库确认
查看当前实例下有哪些数据库，最简单的是：
SHOW DATABASES;这能看到你有权限访问的所有库。如果你是用root登录，会看到MySQL自带的几个系统库——information_schema、mysql、performance_schema、sys。看到它们不要慌，不是入侵迹象，是系统舌头。
有时候你已经登录了好几个连接，容易搞混当前在哪个库。执行：
SELECT DATABASE();如果返回NULL，说明你当前没有选中任何数据库，这时候执行表操作会直接报“No database selected”。这应该是新手最常见的一条报错，原因不是我笨，是根本忘记切库了。解决方案也简单，在SQL前面加上USE语句，或者连接时就指定库名，比如：
mysql -u root -p mydb这样登录进去默认就选中mydb，省去一次USE。
3.2 深一层：查看库的元信息与表清单
只看库名往往不够，你还需要知道这个库里有什么表，表结构是什么样的。这一层级的信息，日常用得也极多。
USE mydb; SHOW TABLES;查看表结构用：
DESC mydb.users;再看表的创建语句：
SHOW CREATE TABLE mydb.users;这几条命令我几乎每天都要用，尤其在排查线上问题的时候。它们的价值在于能让你快速了解库里的实体结构，避免去可视化工具里鼠标点半天。
如果你想做更复杂的过滤，比如只看名字里包含"order"的库：
SHOW DATABASES LIKE '%order%';MySQL 8.0还可以从information_schema里查：
SELECT schema_name FROM information_schema.schemata WHERE schema_name LIKE '%order%';这种写法的好处是，它可以和其他条件组合，比如按创建时间排序、过滤出某些特定前缀的库。这在批量管理多个环境时非常有用——比如我管理几十套测试环境的库，命名规律都是test_开头，一条SQL就能把所有测试库捞出来，再配合后面的删除操作做批量清理。
3.3 一个容易忽略的细节：连接对象中的库名
有一点常常被忽略：你通过命令行或者客户端连接MySQL时，显示的库列表，只包含你拥有权限的库。也就是说，如果A账号只能访问db1，执行SHOW DATABASES只会看到db1和系统库，而不是实例上的全部库。这个设计很安全，但也常让人误解，以为是数据丢失了。遇到“我的库怎么不见了”这种问题，第一件事别急着恢复，先检查当前登录账号的权限。
PostgreSQL下对应的查看逻辑也类似：
\l以及切换库：
\c mydb如果你用的是PostgreSQL的psql命令行，注意它的登录命令默认连接的是同名数据库，比如你执行psql -U postgres，可能会报错“database postgres does not exist”。解决方案是登录时指定库名，或者先连默认库再切换。
4. 选择数据库：USE语句背后的连接思维
4.1 USE语句的原理：修改当前会话的默认库
选择数据库，在MySQL里核心语句就是USE：
USE mydb;从原理上来说，USE语句并不真正“切换服务器上的某个东西”，它只是修改当前会话（session）的默认数据库。你可以把它理解为在文件系统里用cd切换目录——文件还在，只是你的工作路径变了。这个类比大多数情况下成立，对新手理解很有帮助。
USE之后，你执行SELECT、INSERT、UPDATE、DELETE时，SQL语句中的表名都会优先在mydb这个库里寻找。比如：
SELECT * FROM users;等价于：
SELECT * FROM mydb.users;但有一点要特别注意：如果你在同一个会话里执行多次USE，那之前的默认库就会被“忘记”。这对事务和跨库操作有影响。比如你在db1里开了个事务，执行了一批写操作，然后USE db2再去查数据，事务并没有被中断，但后续语句的影响范围已经变了。这个切换发生在事务中时，很容易让人产生“数据去哪了”的错觉。
所以我的建议是：一个脚本或一个事务内，尽量不要来回切换数据库；如果确实需要操作多个库，用库名前缀的方式直接写全限定名，如图：
SELECT * FROM db1.users JOIN db2.orders ON ...;这样写更清晰，也避免USE状态带来的隐式依赖。
4.2 连接时直接指定默认库
除了USE，还可以在建立连接时直接指定默认库。命令行登录时：
mysql -u root -p mydb这样本地连接默认库就是mydb，相当于连接成功后自动执行了一次USE。如果你用的是Python的PyMySQL或者Java的JDBC，连接串里也可以加库名：
conn = pymysql.connect( host='localhost', user='root', password='123456', database='mydb', charset='utf8mb4' )这种做法的好处是代码里的SQL可以少写一个USE，也让连接意图更明确——每个连接的后端流水都能清晰对应到某个库，对监控和排查都很有帮助。
4.3 多环境下的库名切换：你真正需要的是一层逻辑抽象
在日常开发里，我们经常遇到这样的场景：本地开发用local_db，测试环境用test_db，线上用prod_db。代码里的SQL语句都是固定的，总不能每个环境改一遍SQL吧？这时候不该在SQL层面反复修改USE/库名，而是应该在连接层面做切换。
我在项目里通常用环境变量控制连接参数，比如：
import os import pymysql db_config = { 'database': os.getenv('DB_NAME', 'local_db'), 'user': os.getenv('DB_USER', 'root'), 'password': os.getenv('DB_PASSWORD', '123456'), } conn = pymysql.connect(**db_config)这样数据库选择变成了部署配置的一部分，代码本身不感知环境差异。这个思路比“每换一个环境就改一遍USE语句”靠谱一个量级。
5. 删除数据库：安全底线与误删后的补救
5.1 删除语句本身极其简单，难的是操作纪律
删除数据库的语法：
DROP DATABASE mydb;只有这一条，没有任何带条件的“部分删除”选项——DROP DATABASE会直接删除整个库，连同里面的所有表、索引、存储过程、视图，全部物理删除。这个操作没有回收站，没有二次确认弹窗，回车即消失。
我见过太多刚入门的朋友把DROP DATABASE当成清理垃圾的手段，结果清掉了几个月的业务数据。所以在我的团队里，删除数据库之前必须走三道确认：
第一，确认库名拼写百分百正确。尤其是手敲命令时，多一个空格、少一个字母都可能指向完全不同的库。建议先在SELECT里验证一下：
SELECT schema_name FROM information_schema.schemata WHERE schema_name = 'mydb';第二，确认当前连接选中的不是线上环境。很多事故恰恰是，脚本里用了一套通用连接逻辑，在测试环境里跑得好好的，切到生产配置时忘了改库名，一执行就删了生产的库。
第三，确认做过备份。如果库不大，最直接的办法是导出SQL文件再删。MySQL下用mysqldump：
mysqldump -u root -p mydb > mydb_backup.sql删除之前，我还会再导出一份表结构清单，便于之后重建时知道有哪些表、索引、外键关系。这个清单平时看起来没用，等到需要恢复时就是救命稻草。
5.2 删除之后再恢复：这个流程你最好提前备好
万一手滑删了库怎么办？数据库能不能恢复，完全取决于你在删除之前是否开启了备份机制或者binlog。
MySQL层面常见的恢复手段有两种：
第一种是全量备份恢复。如果你有定时全量备份，直接用备份文件恢复即可。比如用之前的mysqldump文件：
mysql -u root -p < mydb_backup.sql注意，这只能恢复到备份时刻的状态，备份之后新产生的数据会丢失。这也是全量备份方案的天然短板。
第二种是结合binlog做增量恢复。MySQL开启binlog后，我们可以从全量备份恢复后，再重放binlog中从备份时间点到删除时间点之间的操作日志，能将数据恢复到删除之前的瞬间。binlog的日志格式一般设置为ROW模式，里面记录了每一行数据变更前后的值，这也是很多数据同步工具依赖的核心依据。
但需要注意的是，binlog能不能恢复，取决于你删除库时有没有保留binlog。如果你做了DROP DATABASE，但binlog恰好被清理掉或者被别的事务覆盖，那恢复的窗口就会非常小。生产环境里，binlog的保留周期通常要设置足够长，比如至少一周，这样可以大幅降低误删后数据不可恢复的概率。
如果你用的是云数据库，比如阿里云RDS、腾讯云CDB，它们一般都带有自动备份和按时间点恢复（PITR）能力，操作起来比自建MySQL省心得多。但自建MySQL绝不等于“不能恢复”，关键是你的运维习惯要跟上——定期全量备份、binlog完整保留，缺一不可。分布式数据库或者PostgreSQL的情况类似，PostgreSQL有WAL日志机制，配合pg_basebackup全量备份也能实现类似的时间点恢复。
5.3 生产环境删除数据库的“最小伤害法”
如果你在生产上真的必须要删库，比如下线一个彻底废弃的业务模块，推荐走一套相对安心的流程：
第一步，先把库改名。比如把proj_a改成proj_a_archive_20250101，而不是直接DROP。这个阶段让业务无感知，正常运行一段时间，确认没有报错、没有程序过来连接。
第二步，观察一段时间之后再执行DROP。观察期内如果发现还有程序在用，立刻把名字改回去，零风险。
第三步，DROP之前把修改后的库完整导出备份，备份文件存到至少三个不同的位置，包括本机、远程存储、云对象存储。备份做完之后，确认备份文件大小不为0，且能通过gzip压缩解压验证完整性，再动手删除。
这个方法听起来啰嗦，但它是目前我实践下来最稳妥的流程。有一说一，这世上没有100%避免误删的手段，只有把恢复成本压到最低的操作习惯。
6. 高频操作下的防御习惯：把低级错误扼杀在SQL执行之前
聊完具体的增删查选，最后我想分享几件“操作习惯”层面的体会，因为这些往往比SQL本身更能决定你能否在生产环境安全存活。
第一，永远不要在客户端界面里直接双击删除数据库。可视化工具虽然方便，但误触概率远高于命令行——因为图形界面里“删除”按钮的位置太顺手了。命令行操作至少每次都要手打库名，多一道心智确认环节。
第二，尽量养成给数据库操作用代码脚本固化的习惯。比如把“建库、建表、初始化数据”写成一个初始化脚本，用变量控制库名，而不是每次手敲。这样既保证重复环境下的幂等性，也能在脚本中自动加入IF NOT EXISTS这类防护逻辑。
第三，接触线上数据库时，建议严格遵守“只读优先”原则。能用只读账号查询的，绝对不用读写账号；能执行SELECT的，绝不顺手执行UPDATE。很多数据库事故都发生在“顺手”这两个字身上。工作中我特别建议给专人在客户端设置read_only权限，或者通过代理层拦截写操作，这是性价比极高的保护机制。
第四，如果你在团队里维护多个环境的数据库，一定要在连接配置里明确标注环境，比如本地库连接串带localhost字样，生产库连接串带host前缀，或者用不一样的颜色区分终端提示符。别笑，这真的是防呆设计的关键一环。我看到过太多案例：深夜操作，用户名密码都一致，忽然后知后觉发现操作的库竟然是生产库，那一刻的心跳停止感，可以记一辈子。
最后说一点体验上的建议。数据库的这些基础操作，看起来都是几行SQL的事，但越是简单的东西，越需要稳定的肌肉记忆。我的训练方法是，每天在终端里模拟一遍“建库-建表-插入-查看-切换-删除”全流程，并且故意在中间制造一些错误，比如故意拼错库名、故意不选默认库去查数据，然后观察报错。这个过程能帮你建立对错误的敏感度，等真正遇到生产事故时，能更从容地定位问题。
数据库的操作技能，本质上就是这些零散细节积累起来的。《创建、查看、选择与删除》这个系列虽然基础，但它是所有上层操作的地基。地基稳了，后面不管是做数据迁移、读写分离还是分库分表，你都不会心虚。
