The basic problem you have is that everything is recursive and you are attempting to lock pages of data in InnoDB, creating lots of MVCC info. In some case, you may have attempted to lock the same InnoDB page repeatedly. That explains the deadlocks. I have commented on this situation deeply with someone in three separate posts on this same issue:
You need a workaround. You may want to try the following algorithm:
For this example
Step 01) Make a table to collect all father_ids to be updated
DROP TABLE IF EXISTS fathers_to_update;
CREATE TABLE fathers_to_update
(
father_id INT NOT NULL,
PRIMARY KEY (father_id)
);
Step 02) Making a table that will be a FIFO queue. Put the value of 12 into the queue:
DROP TABLE IF EXISTS fathers_to_queue;
CREATE TABLE fathers_to_queue
(
father_id INT,
id INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
);
INSERT INTO fathers_to_queue (father_id) VALUES (12);
Step 03) Get the Count of fathers_to_queue
SELECT COUNT(1) FROM fathers_to_queue;
If the count is 0, goto Step 07)
Step 04) Remove the front number in fathers_to_queue
SELECT MIN(id),father_id INTO @frontndx,@dad FROM fathers_to_queue;
DELETE FROM fathers_to_queue WHERE id = @frontndx;
Step 05) Collect all father_ids from 161_ft_individual whose id is @dad into the queue
INSERT INTO fathers_to_update SELECT father_id FROM 161_ft_individual WHERE id = @dad;
INSERT INTO fathers_to_queue (father_id) SELECT father_id FROM 161_ft_individual WHERE id = @dad;
Step 06) Go back to Step 03
Step 07) Perform a single UPDATE of all records in 161_ft_individual you collected in fathers_to_update
UPDATE fathers_to_update A
LEFT JOIN 161_ft_individual B
USING (father_id)
SET B.total_leg=B.total_leg+@amount;
That's it. I basically performed a preoder tree traversal back up the hierarchy to all records until father_id was NULL, which makes Step 03 stop collecting father_ids.
Give it a Try !!!
UPDATE 2011-12-16 12:18 EDT
Back on October 24, 2011, I actually wrote an algorithm in the MySQL Stored Procedure language to perform preorder tree traversal: Find highest level of a hierarchical field: with vs without CTEs . Hope it helps !!!
Here is some vanilla SQL:
CREATE TABLE RoomTypes
(
RoomType VARCHAR(12) NOT NULL,
UNIQUE (RoomType)
);
CREATE TABLE Zones
(
Zone VARCHAR(10) NOT NULL,
UNIQUE (Zone)
);
CREATE TABLE Rooms
(
RoomType VARCHAR(12) NOT NULL,
Zone VARCHAR(10) NOT NULL,
Name VARCHAR(30) NOT NULL,
UNIQUE (RoomType, Zone, Name),
FOREIGN KEY (RoomType) REFERENCES RoomTypes (RoomType),
FOREIGN KEY (Zone) REFERENCES Zones (Zone)
);
CREATE TABLE NumberedRooms
(
RoomType VARCHAR(12) NOT NULL,
Zone VARCHAR(10) NOT NULL,
Name VARCHAR(30) NOT NULL,
CHECK (RoomType = 'Numbered'),
UNIQUE (Name),
UNIQUE (RoomType, Zone, Name),
FOREIGN KEY (RoomType, Zone, Name)
REFERENCES Rooms (RoomType, Zone, Name)
);
CREATE TABLE AncillaryRooms
(
RoomType VARCHAR(12) NOT NULL,
Zone VARCHAR(10) NOT NULL,
Name VARCHAR(30) NOT NULL,
CHECK (RoomType = 'Ancillary'),
UNIQUE (Zone, Name),
UNIQUE (RoomType, Zone, Name),
FOREIGN KEY (RoomType, Zone, Name)
REFERENCES Rooms (RoomType, Zone, Name)
);
The CHECK
constraints will not be tested by mySQL e.g. do the tests yourself using triggers. Consider adding other tests e.g. that attribute Name
in table NumberedRooms
represents an integer.
The idea that every row in the supertype table Rooms
will have exactly one row in the union of AncillaryRooms
and NumberedRooms
. This is merely implied e.g. have 'helper' procs to add rows to both super- and subtype tables as a single operation and use triggers to ensure it is done.
Note NumberedRooms
has a simple key Name
alone, whereas AncillaryRooms
has a compound key on (Zone, Name)
. All three (non-lookup) tables have a key on (RoomType, Zone, Name)
throughout, allowing further subtype tables to referencing them and maintain integrity by further testing for valid RoomType
values.
Best Answer
GROUP_CONCAT(... ORDER BY ...) as foo
to combine them into a single string.SELECT GROUP_CONCAT(ky) ... GROUP BY foo HAVING COUNT(*) > 1
to get the duplicate kys. (Please don't use the keyword "KEY".)Give that a try. If you get in trouble, show us
SHOW CREATE TABLE
and your failed attempt. (Or abandon EAV.)Some code (not quite mimicking the above prose):
should give you
Then...
should give you
Now...
should give you
I suggest you debug my code the way I wrote it -- test the first query to see if it gives you the first set of output, then second, then third.