上周加班改业务脚本，临时被产品堵在工位追问mysql怎么查看表，手头没有现成文档，只能靠着之前零散记下来的操作步骤在测试服务器里挨个试错，服务器环境是本地搭建的5.7版本，远程连接工具用的Navicat，一开始顺手点开客户端就敲查询语句，完全忽略了切换数据库这个前置步骤，输完show tables之后页面只返回空结果，反复刷新三四次都找不到任何数据表，一度怀疑运维是不是清空了库里的数据，还跑去对接运维核对库文件，白白浪费了二十多分钟的工时，反正那会儿脑子乱糟糟，压根没想起刚连库要选定目标库这件小事。
运维点开终端一眼就点出问题。
原来不管是在黑窗口的mysql客户端，还是可视化的连接软件，刚连上服务实例的时候，系统默认不会自动选定任意一个业务数据库，数据库实例里面会存放数十个不同项目的库，每个库独立存储自身的数据表，没通过use命令切入目标库，查询指令自然读取不到对应内容，按着提醒先输入use shop_db;选定项目在用的店铺数据库，末尾的分号不能漏掉，敲完回车没有报错提示之后，再输入最常用的show tables;，界面瞬间罗列出来当前库下所有的数据表名称，从用户信息表到订单流水表整整齐齐排布在结果栏，那一刻才算把卡住的查询操作理顺，那个时候才发觉之前自学的时候囫囵吞枣，跳过了数据库和数据表从属关系的细节，才卡在这么基础的操作上面。
后续顺手试了另一条指令，show full tables;，这条会额外标注表的类型，区分普通数据表和视图，平常排查视图冗余的时候会频繁用到，就是字符输入比基础指令多几个，赶时间查表名的时候很少优先选用，偶尔需要分辨视图和实体表才会切换这条语句。
身边做运维的同事偏爱用information_schema系统库查表，他习惯先切换到这个系统自带库，再拼接select table_name from tables where table_schema='shop_db';这类筛选语句，能附带带出表的存储引擎、创建时间等附加信息，只是语句偏长，新手很容易写错库名的引号格式，单双引号混用就会直接报语法异常，我试过两次，常常在表名字段的引号位置写错，来回修改好多次才能正常查出数据，平时简易查表基本不会选用这种写法。
本地免安装版mysql还能靠命令行参数快速调取。
之前在自己电脑搭的测试环境，没打开客户端界面，直接在cmd终端输入mysql -e "use shop_db;show tables;" -uroot -p，回车输完数据库密码就能直接在黑框打印表清单，不用一步步进入交互界面，批量跑脚本的时候这个写法省心不少，唯独要留意密码参数不要明文写在命令里，容易泄露权限信息，日常实操基本都会省略-p后面的明文密码字段，避免账号信息暴露在运行日志里面，这点是踩过泄露小隐患之后慢慢养成的操作习惯。
偶然试过desc 表名的写法，这个指令不能罗列全库表格，只能查看单张表的字段结构，不少新人会混淆这条和查表清单的命令，拿着desc去查全库所有表，最后只能拿到报错信息，这也是实操里高频出现的操作误区，之前带过的实习生就反复踩过这个错，分不清查表清单和查表字段的两条指令。
忙完当天的需求，关灯收拾键盘的时候，脑子里还盘旋着刚才反复踩过的操作疏漏，随手在记事本记下两条核心查询语句，之后就没再在同类问题上绕弯路。