Зависи; пуснете и двамата, за да разберете; след това стартирайте 'explain select' за обяснение.
Действителната разлика в производителността може да варира от „практически несъществуваща“ до „доста значителна“ в зависимост от това колко реда в A с id='12345' нямат съвпадащи записи в B и C.
Актуализиране (въз основа на публикувани планове за заявки)
Когато използвате INNER JOIN, няма значение (по отношение на резултатите, а не по отношение на производителността) с коя таблица да започнете, така че оптимизаторът се опитва да избере тази, която смята, че ще работи най-добре. Изглежда, че имате индекси за всички подходящи колони PK / FK и или нямате индекс на friend_events.userid или има твърде много записи с userid = '13006' и не се използва; така или иначе оптимизаторът избира таблицата с по-малко редове като "база" - в този случай това е zcms_users .
Когато използвате LEFT JOIN, това прави има значение (по отношение на резултатите) с коя таблица да започнем; така friend_events е избран. Сега защо по този начин отнема по-малко време, не съм съвсем сигурен; Предполагам friend_events.userid състоянието помага. Ако добавите индекс (действително ли е varchar, между другото? не е числов?) към него, вашето INNER JOIN също може да се държи по различен начин (и да стане по-бърз).
