An issue you may encounter on larger sites is massive DB load spikes when there is a high order volume and large number of customers stored in the DB. The problem stems from the Enterprise Edition’s Customer Segments module and the way it checks to add a new customer into a segment.
The main culprit is the Enterprise_CustomerSegment_Model_Segment_Condition_Combine_Root class, specifically the _prepareConditionsSql method. This is what generates the SQL that will be run to verify if a customer should be added to this segment when they place an order or sign up. It generates a query like:
SELECT 1 FROM `customer_entity` AS `root` WHERE (( IF(( SELECT 1 FROM `sales_flat_order_item` AS `item` INNER JOIN `sales_flat_order` AS `sales_order` ON item.order_id = sales_order.entity_id INNER JOIN `core_store` AS `store` ON sales_order.store_id=store.store_id WHERE (sales_order.customer_id = '11111111') AND (store.website_id='1') AND (EXISTS (SELECT `main`.`entity_id` FROM `catalog_product_entity` AS `main` WHERE (main.sku = 'ITEM1') AND (main.entity_id = item.product_id))) LIMIT 1 ), 1, 0) = 1 ))
which has a major issue, the main outer query has no limit! Even worse, it has no where condition to limit the number of rows being returned so what you get is a HUGE amount of rows containing “1” whenever the inner customer+item match is true. When you have 1 million or more customers, this can lead to the DB creating temporary tables on disk since it no longer fits in the maximum memory temp table size which leads to load spikes if you are getting any sizable amount of orders being placed. Continue reading
If you use Magento EE and have enabled Solr for search, you may run into a few issues depending on how you customize your template. One issue is that the Enterprise Search engine for Solr does not properly handle resetting the result count when 0 results are found. The other two have to do with the way it indexes the data; it does not properly add some attributes to the index if you only have “Used for Sorting in Product Listing” enabled and/or they are the datetime attribute type on non-simple products.
The first one is relatively easy to reproduce but probably is not run into very often. On a website I was developing, the client wanted to break out the search results into individual categories and display the top few of each category results on the page. The page would then link out to each individual category to view all the results inside that category. The problem we found was that, if the previous category returned results and the current one it was outputting had none, it would still think that it had the same number of results as the previous category.