We have a fairly large database, set up via Symfony+Doctrine, which has been in the running for a while. Some of those entities are made with SoftDeletableTrait at the time. Some of those entities no longer required softdelete so we're going to delete the rows with a 'deletedAt' value and then drop the SoftDeletableTrait.
We need to find which tables/rows are referenced currently, example:
TableA
ID name deleted_at
1 Foo NULL
2 Bar 01-01-2020 10:11:12
I want all tables and rows referencing to TableA id=2:
TableFoo id=19
TableFoo id=21
TableBar id=7
If it where one table, we could do an subquery or join to complare it with one other table, but we dont know the amount of other tables.
We Could check the entity and see all it's references, but TableA isn't the only table getting scrubbed, there are about 10 large tables, so we're looking for a (semi-)automatic method.
I have the following query
select count(t1.guid)
from table t1
where t1.id=X;
X is a result-set from this query
select ID
from table t2
where t2.flags=65537;
The above query returns 84 results, all of INT datatype.
id is primary key in t2 table,
and foreign key in t1 table;
guid is primary key in t1 table,
and doesn't exist anywhere else.
Object O1 has a unique identifier among the table that declares all objects and their properties (t2)
GUID in table t1 assigns unique identification to every instance of object O1 called by upper layers.
I want to see the number of duplicates every object that fulfills conditions in the second query.
I suppose I should go about declaring a variable and a function that uses said variable but got no clue where to start or how to go about it.
I solved the problem once with hand-hacking 84 times, but looking for a more elegant and more adaptive solution to this;
After a whole day spent, figured it out
Simply link the two posted queries together, but change the "=" operator to "in"
select count(t1.guid)
from table t1
where t1.id in
(select t2.ID
from table t2
where t2.flags=65537);
hand-hacking session avoided!
I have a table 'orders' with fields
id
user_id
project_id
etc..
where two type of selects
select * form orders where user_id = val1
and
select * form orders where user_id = val1 and project_id = val2
If I create multi colum index for second type of selects on user_id+project_id Do i need to create
one column index on user_id to spped up first type of selects?
You only need one index for the table . . . orders(user_id, project_id). This can be used for both queries because the left most keys (user_id) have an equality condition in the first query. However, the keys need to be in this order.
MySQL has pretty good documentation on multi-column indexes.
Let's say I have a table with 10 records labeled 1 through 10, and each record contains two fields. I want to create a query that shows me Field 1 of record N with Field 2 of record N+1. For example, the query would show Field 1 of record 3 with Field 2 of record 4. Is this possible?
It is possible not particularily complex.
Given a table tblFoo with FooId as Primary Key and the two additional fields FooText and BarText, the SQL to get the desired results would look like this:
SELECT f1.FooText, f2.BarText
FROM tblFoo AS f1
LEFT JOIN tblFoo AS f2
ON f1.FooID +1 = f2.FooID
While it is simple to implement, performance will no be ideal for large tables because the expression FooId+1 prevents the query engine to use the primary key as index while retrieving the results.
i am currently writing query. i want to select all records from table . records will be based on mutiple values of foreign key. for example all records related to 1 and 2 both
eg. table might have
id name uid
1 bil 3
2 test 3
3 test 4
4 test 4
5 bil 5
6 bil 5
i want to select all records related to 3 but also related to 4 in this case it is record number 2
SELECT id
FROM `table`
WHERE uid = value1 AND like_id
IN (SELECT like_id
FROM likes
WHERE uid = uid2)
LIMIT 0 , 30
It's not at all clear where "value1" is coming from, or "uid2" is coming from, or where the column "like_id" is coming from. Those column names do not appear in your sample table. Your example query references two different table names (table and likes), yet you only show data for one example table, and that table does not have a column named like_id.
If we assume that "value1" and "uid2" in your query are literals, or bind parameters supplied to the query, which seems to be reasonable, given your specification (variously), of values of 1,2,3 and 4. But we're still left with "like_id" column. Given that it's referenced in the SELECT list of the IN subquery, we're going to presume that's a column in the "likes" table, and given that it's referenced in the outer query, we're going to assume that it's a column in the (unfortunately named) table table.
(Bottomline, it's not at all clear how your query is returning a "correct" result, given that you've made it impossible to replicate a working test case.)
Given a single table, as shown in your example data, e.g.
CREATE TABLE likes (id INT, name VARCHAR(4), uid INT);
INSERT INTO likes VALUES (1,'bil',3),(2,'test',3),(3,'test',4)
,(4,'test',4),(5,'bil',5),(6,'bil',5);
ALTER TABLE likes ADD PRIMARY KEY (id);
ALTER TABLE likes ADD CONSTRAINT likes_ix UNIQUE KEY (uid, name);
Assuming that we're running a query against that single table, and that we're matching "likes" associated with uid=3 to "likes" associated with uid=4, and that the matching is done on the "name" column, then
SELECT t.id
FROM `likes` t
WHERE t.uid = 3
AND EXISTS
( SELECT 1
FROM `likes` s
WHERE s.name = t.name
AND s.uid = 4
)
That will return the id of the row from the likes table for uid=3 where we also find a row in the likes table for uid=4 with a matching name value.
Given a limited number of rows to be inspected from the likes table on the outer query, that gives a limited number of times a correlated subquery would need to be run, which should give reasonable performance:
For large sets, a join operation generally performs better to return an equivalent result:
SELECT t.id
FROM `likes` t
JOIN `likes` s
ON s.name = t.name
AND s.uid = 4
WHERE t.uid = 3
GROUP
BY t.id
The key to optimum performance for either query is going to be appropriate indexes.