On Thu, March 31, 2011 12:33, mos wrote:
> At 11:20 AM 3/31/2011, you wrote:
>>At 07:29 AM 3/31/2011, you wrote:
>>>Thanks for your insight! But I'm still worried about the performance of
>>>IN ( big list of values ). Can you tell me how it is implemented?
>>>
>>>Suppose I have SELECT a FROM b WHER
At 11:20 AM 3/31/2011, you wrote:
At 07:29 AM 3/31/2011, you wrote:
Thanks for your insight! But I'm still worried about the performance of
IN ( big list of values ). Can you tell me how it is implemented?
Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ...,
387945)
1) If
- Original Message -
> From: "mos"
>
> The IN() clause is very inefficient because MySQL will NOT use the
> index.
> It will have to traverse the entire table looking for these values.
Has that still not been remedied ?
> It will get the information from the index and not have to acce
At 07:29 AM 3/31/2011, you wrote:
Thanks for your insight! But I'm still worried about the performance of IN
( big list of values ). Can you tell me how it is implemented?
Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ...,
387945)
1) If I put 200 values there, does it do
- Original Message -
> From: "Gregory Magarshak"
> I am guessing that the MySQL indexes map indexed fields (fb_uid) to the
> primary key (id) so I wouldn't have to touch the disk. Am I right
> about that?
Correct for InnoDB, but MyISAM maps every index straight onto records. That's
why
By the way, sorry ... I wanted to clarify one thing:
I am trying to FILTER by the unique index (fb_uid) in this case, but
JOIN on the primary key (id) and I don't need to use any other fields. I
am guessing that the MySQL indexes map indexed fields (fb_uid) to the
primary key (id) so I wouldn'
Thanks for your insight! But I'm still worried about the performance of
IN ( big list of values ). Can you tell me how it is implemented?
Suppose I have SELECT a FROM b WHERE c IN (1, 4, 5, 117, 118, 119, ...,
387945)
1) If I put 200 values there, does it do 200 individual SELECTs
internally
Hi Gregory,
Are you sure you'd like to do this using MySQL? What would happen if you
start using sharding?
Maybe you could consider using a stack (stored in a tool like Redis?).
Whenever some user adds some item, you add primary key of the new item
to the "network updates" stack of each frie
> Why not optimize the IN ( ... ) to do the same type of thing?
If the argument to IN() is a list of values, it'll be OK. If it's a
SELECT, in 5.0 it will be slower than molasses (see "The unbearable
slowness of IN()" at http://www.artfulsoftware.com/queries.php.
> I always tried to avoid joi
Yes, this would be fine. But often, the list of friends is obtained from
a social network like facebook, and is not stored internally. Basically,
I obtain the friend list in a request to facebook, and then see which of
those users have created things. So would I have to create a temporary
table
> How can I quickly find all the articles written by this user's
friends, and not just random articles?
Taking the simplest possible case, with table friends(userID,friendID)
where each friendID refers to a userID in another row, the friends of
userID u are ...
select friendID from user wher
Hey there. My company writes a lot of social applications, and there is
one operation that is very common, but I don't know if MySQL supports it
in a good way. I thought I'd write to this list for two reasons:
1) Maybe MySQL has a good way to do this, and I just don't know
about it
2
12 matches
Mail list logo
