创建MySQL存储过程lip_StoreItem时遇1310错误求助

Hey there, let's work through this error you're hitting with your MySQL stored procedure. The 1310 - End-label $$ without match error usually pops up when MySQL can't properly match the closing END $$ of your procedure with its opening structure—often because of a hidden syntax mistake elsewhere in your code or issues with delimiter handling.

Common Causes & Fixes for Your Code #

Let's break down the likely issues and how to fix them:

1. Delimiter Misconfiguration
   First, make sure you're setting the delimiter correctly before defining the procedure, and resetting it afterward. Your code starts with DELIMITER $$ which is right, but ensure you don't accidentally reset the delimiter mid-procedure. When executing the full script, run the delimiter command first, then the procedure definition, and finally DELIMITER ; to restore the default.

2. Syntax Errors in the items_attributes Insert
   The error message points directly to the INSERT INTO items_attributes line—this is a key clue. MySQL hit a syntax error here and couldn't finish parsing the procedure, leading it to incorrectly think the closing END $$ doesn't match. Check these details:

   • Verify all column names match your actual items_attributes table (no typos like defence_fire vs a shorter name like def_fire).
   • Ensure every value in the ON DUPLICATE KEY UPDATE clause is separated by commas, with no trailing comma at the end.
   • Confirm all parentheses are balanced in the INSERT statement—even one missing closing parenthesis will throw off the entire parsing.

3. Nested BEGIN/END Matching
   You're using a labeled block entry: BEGIN with LEAVE entry—this is valid, but double-check that all nested BEGIN/END pairs inside your CASE statement are properly closed. Count up the BEGIN and END statements in your code: they should be equal (your code has 4 BEGINs and 4 corresponding ENDs, which looks correct, but it's easy to miss one when editing complex logic).

Step-by-Step Debugging Tip #

If you're still stuck, simplify the procedure to isolate the error:

• Comment out the entire CASE statement block, leaving only the initial IF check and the main INSERT INTO items line.
• Try creating the procedure—if it works, you know the issue is inside the CASE logic.
• Uncomment one CASE branch at a time, testing after each change, until you hit the line that causes the error. This will pinpoint exactly where the syntax mistake lives.

Cleaned-Up Snippet for the Problematic Section #

Here's a formatted version of the items_attributes block to make syntax issues easier to spot (assuming your table columns match):

IF ((iAttackType > -2) AND (iAttackVal > 0)) OR 
   (iDefFire > 0) OR (iDefWater > 0) OR (iDefWind > 0) OR 
   (iDefEarth > 0) OR (iDefHoly > 0) OR (iDefUnholy > 0) THEN
    INSERT LOW_PRIORITY INTO `items_attributes` (
        `item_id`, `attack_type`, `attack_value`, 
        `defence_fire`, `defence_water`, `defence_wind`, 
        `defence_earth`, `defence_holy`, `defence_unholy`
    ) VALUES (
        iItemID, iAttackType, iAttackVal, 
        iDefFire, iDefWater, iDefWind, 
        iDefEarth, iDefHoly, iDefUnholy
    ) ON DUPLICATE KEY UPDATE 
        `attack_type` = iAttackType,
        `attack_value` = iAttackVal,
        `defence_fire` = iDefFire,
        `defence_water` = iDefWater,
        `defence_wind` = iDefWind,
        `defence_earth` = iDefEarth,
        `defence_holy` = iDefHoly,
        `defence_unholy` = iDefUnholy;
ELSE
    DELETE LOW_PRIORITY FROM `items_attributes` WHERE `item_id` = iItemID LIMIT 1;
END IF;

Breaking long lines into readable chunks makes it much easier to spot typos or missing punctuation.

内容的提问来源于stack exchange，提问作者Arunas Jaspelkis