sql server 存储过程无法直接迁移到 mysql，因二者语法体系不同：变量声明位置、赋值方式、游标结构、错误处理、事务控制及函数功能均不兼容，必须重写逻辑。
不能靠“替换函数名”蒙混过关，SQL Server 和 MySQL 存储过程是两套语法体系，直接迁移必然报错——GO、@variable、TRY...CATCH、DECLARE @t TABLE 在 MySQL 里全不认。
MySQL 不支持 SQL Server 的变量声明和赋值写法
SQL Server 常用 SELECT @var = col FROM t 赋值，MySQL 必须拆成两步：SELECT col INTO var FROM t 或显式 SET var = (SELECT col FROM t LIMIT 1)。更关键的是声明位置：MySQL 要求所有 DECLARE 必须紧贴 BEGIN 后，不能穿插在逻辑中间；而 SQL Server 允许随时声明。
- 错误写法（MySQL 报
ERROR 1064）：BEGIN IF ... THEN DECLARE v INT DEFAULT 0; END IF; - 正确顺序（MySQL 强制）：
BEGIN DECLARE v INT DEFAULT 0; DECLARE done TINYINT DEFAULT FALSE; ... - 赋值语句别混用：SQL Server 的
ISNULL()换成 MySQL 的IFNULL()只是第一步，后面整个变量流控结构都得重排
游标和循环结构无法直接对应
SQL Server 游标靠 FETCH NEXT FROM cur INTO @a, @b + WHILE @@FETCH_STATUS = 0 驱动；MySQL 必须用 REPEAT ... UNTIL done END REPEAT，且必须提前声明 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE 来捕获结束信号——漏掉这句，游标会无限循环或跳过最后一行。
- SQL Server 隐式处理游标边界，MySQL 显式依赖
done标志位 -
WHILE在 MySQL 中不支持条件后置，只能用REPEAT或LOOP+LEAVE - 批量操作优先改写为单条 SQL：比如 SQL Server 的游标更新，尽量转成 MySQL 的
UPDATE ... JOIN，避免过程式逻辑
错误处理机制完全不同
SQL Server 的 TRY...CATCH 块在 MySQL 里没有等价语法，必须用 DECLARE ... HANDLER 捕获特定条件（如 SQLEXCEPTION、SQLWARNING），且 SIGNAL 抛异常只支持 SQLSTATE 码（如 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'），不能像 RAISERROR 那样带严重级别和状态参数。
- MySQL 的 handler 是“按条件注册”，不是“按范围包裹”，无法嵌套或局部屏蔽
- 事务控制需手动配对：
START TRANSACTION+ROLLBACK/COMMIT，没有SAVE TRANSACTION这种中间点 - 别指望
@@ERROR或@@ROWCOUNT—— MySQL 没有这些全局状态变量
部分特性根本无替代，必须换思路实现
像 SQL Server 的 OUTPUT INSERTED.*、WITH (NOLOCK)、STUFF()、GETDATE() 这类功能，在 MySQL 中要么没有直接等价物，要么语义不同。硬翻译只会埋坑。
-
OUTPUT→ 改用INSERT+SELECT LAST_INSERT_ID()（仅限自增主键），或加临时表中转 -
WITH (NOLOCK)→ MySQL 默认 MVCC 快照读，无需提示；若真要读未提交，得设会话级SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED -
GETDATE()→ 统一用NOW()或CURRENT_TIMESTAMP（ANSI 标准），别碰SYSDATE()（行为受时区影响） - 字符串拼接：SQL Server 用
+，MySQL 必须用CONCAT()，且NULL任一参数会导致整结果为NULL，得先IFNULL()处理
最易被忽略的其实是字符串比较和排序规则：SQL Server 默认不区分大小写（取决于数据库 COLLATION），MySQL 则由字段 COLLATION 决定（如 utf8mb4_0900_as_cs 区分大小写）。WHERE name = 'ABC' 在两边可能返回完全不同的结果集——这个差异不会报错，但会让业务逻辑静默出错。
