I don't mean to be a grouch, but I've had this issue posted in a bug since September 14, and haven't heard a single thing about it. The link to the bug:
http://bugs.mysql.com/bug.php?id=62436
Basically, using INSERT IGNORE INTO, or anything with AUTO_INCREMENT where the increment may not actually happen, gives me unexpected results in a cluster. In other words, the AUTO_INCREMENT column will *always* increment on a cluster, even if INSERT IGNORE INTO finds a matching key and performs no insert.
The INSERT IGNORE INTO syntax is one of the best MySQL features, IMO, because it (a) simplifies my code, and (b) speeds up my program (avoids SELECT followed by UPDATE calls).
Has anyone else experienced this issue? If so, how did you work around it? I'm hoping to avoid two calls (SELECT then UPDATE) if at all possible.
And, secondly, not to be rude, but can someone explain the bug procedure to me? Maybe I'm blowing this out of proportion, but this seems to me like an obvious mismatch between the documentation and the actual performance, yet apparently no one is paying attention to the bug report. It's not just me; I counted 89 bugs currently in the "Analyzing" stage - one even dating back to December 2005!
http://bugs.mysql.com/bug.php?id=62436
Basically, using INSERT IGNORE INTO, or anything with AUTO_INCREMENT where the increment may not actually happen, gives me unexpected results in a cluster. In other words, the AUTO_INCREMENT column will *always* increment on a cluster, even if INSERT IGNORE INTO finds a matching key and performs no insert.
The INSERT IGNORE INTO syntax is one of the best MySQL features, IMO, because it (a) simplifies my code, and (b) speeds up my program (avoids SELECT followed by UPDATE calls).
Has anyone else experienced this issue? If so, how did you work around it? I'm hoping to avoid two calls (SELECT then UPDATE) if at all possible.
And, secondly, not to be rude, but can someone explain the bug procedure to me? Maybe I'm blowing this out of proportion, but this seems to me like an obvious mismatch between the documentation and the actual performance, yet apparently no one is paying attention to the bug report. It's not just me; I counted 89 bugs currently in the "Analyzing" stage - one even dating back to December 2005!
