mysql数据库语句大全

MySQL的据库增删改查，说白了就是语句四个动词：INSERT、DELETE、大全UPDATE、据库SELECT。语句真正常用的大全语句不超过二十条，剩下的据库绝大多数是应付特殊场景的变体。我见过不少号称“精通MySQL”的语句人，连一条带窗口函数的大全UPDATE都写不利索。

先说说建表。据库CREATE TABLE这条语句，语句很多人只写个皮毛。大全你见过带注释的据库表结构吗？
CREATE TABLE users ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
这行代码里藏着三个坑：第一，INT要加UNSIGNED，语句不然你存不了40亿以上的大全数据；第二，ENGINE必须指定InnoDB，MyISAM不支持事务；第三，utf8mb4不是utf8，emoji字符存不进去的时候你就知道区别了。

查询语句才是重头戏。SELECT * FROM table这种写法，生产环境里谁写谁挨骂。要什么字段就查什么字段，别把整张表拖出来。JOIN连接的时候，left join和inner join的结果可能天差地别——你漏掉一行NULL数据，报表就错了。有个真实案例：某电商平台统计订单金额，用inner join把未支付订单全过滤掉了，结果报表比实际营收高了30%。

再说说WHERE条件里的门道。索引失效的情况比你想的多：对索引列使用函数、隐式类型转换、LIKE前置通配符——这些都会让索引变成废纸。我见过最离谱的写法是WHERE DATE(created_at) = '2024-01-01'，明明可以写成WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'。前者全表扫描，后者走索引，性能差十倍不止。

UPDATE和DELETE要格外小心。不带WHERE条件的UPDATE就是灾难——全表数据都被改了。建议养成习惯：先SELECT确认影响行数，再改成UPDATE。MySQL有个安全模式，SET SQL_SAFE_UPDATES = 1;，强制要求WHERE条件，新手最好开着。

INSERT也有讲究。批量插入别一条条执行，用一条语句搞定：
INSERT INTO users (username, email) VALUES ('张三', 'a@test.com'), ('李四', 'b@test.com'), ('王五', 'c@test.com');
这样比三条INSERT快好几倍。还有INSERT ... ON DUPLICATE KEY UPDATE这个语法，专门处理主键冲突时更新数据，省得先查再改两步走。

事务控制这块，BEGIN、COMMIT、ROLLBACK三个命令必须烂熟于心。转账场景：A扣钱、B加钱，两步必须在一个事务里。中途任何一步失败，ROLLBACK全部回滚。MySQL默认autocommit=1，每次语句自动提交，但多步操作必须显式开启事务。

索引管理是优化重点。CREATE INDEX idx_username ON users(username); 这条语句谁都会写，但复合索引的顺序很关键——(a,b)和(b,a)是两个完全不同的索引。最左前缀原则：查询条件必须以a开头才会用到这个复合索引。

最后提一嘴SHOW语句。SHOW PROCESSLIST查看当前连接状态，SHOW INDEX FROM table查看索引详情，EXPLAIN SELECT ...分析执行计划——这三条命令是排查性能问题的三板斧。遇到慢查询，先EXPLAIN看看有没有走全表扫描，再考虑优化方案。

MySQL的语句说来说去就这些，但用好和用不好差距巨大。写代码前先想想数据量级，再决定怎么写SQL。一万行和一百万行的表，写法完全不同。