Yeah, seems like for a uniquely index column expression that the LIMIT 1 provides no benefit (which seems like a logical conclusion). The performance on a large data set with both approaches is close enough to call equivalent.
-----Original Message----- From: Rick James [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 11:51 AM To: Robert DiFalco; mysql@lists.mysql.com; [EMAIL PROTECTED] Subject: RE: Performance: LIMIT 1 with UPDATE Maybe it is the tiny extra time to parse the unnecessary " LIMIT 1"? > -----Original Message----- > From: Robert DiFalco [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 29, 2006 10:09 AM > To: mysql@lists.mysql.com; [EMAIL PROTECTED] > Subject: RE: Performance: LIMIT 1 with UPDATE > > FWIW, my preliminary testing shows no performance increase for adding > LIMIT 1 to the following construct: > > [ SELECT | UPDATE ] > WHERE Table.UniqueID = <N> > > In fact, there seems to be a slight performance edge to NOT appending > LIMIT 1 to the statement. > > R. > > -----Original Message----- > From: Robert DiFalco [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 29, 2006 9:06 AM > To: mysql@lists.mysql.com > Subject: Performance: LIMIT 1 with UPDATE > > Does using LIMIT 1 with UPDATE provide a performance improvement when > the WHERE condition is on a unique index or primary key? > > R. > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > > > -- > MySQL Internals Mailing List > For list archives: http://lists.mysql.com/internals > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
