MySQL这东西，使用说穿了就是教程个存数据的仓库。但很多人一上来就被各种术语吓住，使用其实你只需要记住一件事：会写SELECT，教程你就已经入门了。使用我见过太多人花两周时间研究索引优化，教程结果连最基本的使用JOIN都没搞明白——这纯属本末倒置。
先装个环境。教程别碰那些图形化工具，使用直接用命令行。教程打开终端敲mysql -u root -p，使用输密码进去，教程看到mysql>提示符就对了。使用这时候你面对的教程是一个空荡荡的数据库服务器，就像刚租的使用毛坯房——得先建库建表才能住人。
建库的语法简单到发指：CREATE DATABASE test; 然后USE test;切进去。真正考验人的是建表。我当年第一次建表时，把用户名设成VARCHAR(10)，结果存了个11位的手机号直接报错——字段长度宁大勿小，这是血泪教训。一个规范的users表大概长这样：
CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );插数据用INSERT，查数据用SELECT，改数据用UPDATE，删数据用DELETE。这四条命令覆盖了日常90%的操作。但真正让MySQL发挥威力的是WHERE子句——不加WHERE的DELETE是全表自杀，加错WHERE是定向误伤。我见过有人写DELETE FROM orders WHERE status='pending'结果把三个月前的pending订单全清了，因为业务逻辑里早该把这些订单改成cancelled了。
查询这块，很多人栽在JOIN上。其实LEFT JOIN和INNER JOIN的区别就一句话：LEFT JOIN保留左表所有行，右边没匹配就填NULL。举个实际场景——你要查所有用户最近一笔订单，这么写：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id = (SELECT MAX(id) FROM orders WHERE user_id = u.id);这个子查询可能不是最优解，但至少能跑。MySQL优化是后面的事，先保证结果正确。很多人一上来就背索引口诀，什么“最左前缀”“覆盖索引”，结果连EXPLAIN输出都看不懂——这跟没学一样。
日常使用中，你迟早会遇到ERROR 1064或者ERROR 1146。前者是语法错误，多半是逗号或引号写错位置；后者是表不存在，八成是你USE了错误的数据库。这两类错误占了我早期踩坑的70%。遇到报错别慌，先看错误码，再查对应含义——比瞎试强得多。
备份这事必须说。用mysqldump -u root -p test > backup.sql导出的文件，在另一台机器上mysql -u root -p test < backup.sql就能恢复。我有个习惯：每次改动表结构之前先备份，哪怕只是加个字段。这习惯救过我无数次，尤其是当你在生产环境手滑删错数据的时候——那种情况下，备份就是你的后悔药。
最后说点实在的。MySQL的默认配置其实挺保守，你本地测试根本感觉不到瓶颈。但如果你要处理百万级数据，记得给常用查询字段加索引：CREATE INDEX idx_user_id ON orders(user_id); 就这么一行，能让查询从全表扫描变成索引查找，速度提升几十倍。别问为什么，先加上再说——等你哪天在慢查询日志里看到某条SQL执行了五秒，自然就懂了。
写到这里，其实你已经掌握了MySQL的生存技能。剩下的什么存储引擎、事务隔离级别、主从复制，都是后话。先把数据存进去，查出来，别丢——这就够了。