对于我的初创公司，我自己跟踪一切，而不是依赖谷歌分析。这很好，因为我实际上可以有IP和用户ID以及所有东西。
直到我的跟踪表上升了大约200万行，这一切都很顺利。该表称为acts，并记录：
知识产权
网址
笔记
帐户ID
…如果有的话。
现在，尝试这样做：
SELECT COUNT(distinct ip)
FROM acts
JOIN users ON(users.ip = acts.ip)
WHERE acts.url LIKE '%some_marketing_page%';
基本上不会结束。我换了这个：
SELECT COUNT(distinct ip)
FROM acts
JOIN users ON(users.ip = acts.ip)
WHERE acts.note = 'some_marketing_page';
尽管有一个值得注意的指数，但它仍然非常缓慢。
我显然不擅长mysql。我的问题是：
拥有大量数据的公司如何跟踪漏斗转换率之类的事情？在mysql中可以这样做吗？我只是缺少一些知识？如果没有，我可以阅读哪些书籍/博客来了解网站是如何做到这一点的？
最佳答案
在走向“体面”的同时，200万行对于一个表来说仍然是一个相对较小的大小。（因此，通常可以实现更快的性能）
正如您所发现的，前端通配符特别低效，如果您的应用程序使用这种用例是常见的，我们将不得不找到解决方案。
可能是您没有正确的索引集。然而，在我继续之前，我想强调的是，虽然索引通常会通过各种select语句来提高dbms的性能，但它系统地对“cud”操作的性能有负面影响（即使用sql create/insert、update、delete动词，即写入数据库而不是仅仅读取数据库的查询它）。在某些情况下，索引对“write”查询的负面影响可能非常显著。
我之所以特别强调索引的矛盾性质，是因为似乎您的应用程序在其操作的正常部分中进行了大量的数据收集，并且您将需要注意插入查询的速度将减慢时可能出现的降级。一种可能的替代方法是将数据收集到一个相对较小的表/数据库中，没有索引或索引很少，并定期将数据从这个输入数据库导入到一个进行实际数据挖掘的数据库中。（导入后，可以从“输入数据库”中删除行，使其保持小而快的插入功能。）
另一个关注点/问题是转换表中行的宽度（列的数量和这些列的宽度之和）。糟糕的性能可能与行太宽的事实有关，这会导致表的叶节点中的行太少，从而导致比所需的树结构更深。
回到索引…
考虑到问题中的少数查询，似乎可以从IP+注释索引（至少按此顺序使用这两个键创建的索引）中获益。这里无法对索引情况进行全面分析，坦率地说，也无法对数据库模式进行可能的检查（没有足够的信息支持……），但这样做的一般过程是列出最常见的用例，并查看哪些数据库索引可以帮助处理这些用例。使用mysql命令explain，您可以深入了解如何处理特定查询（最初或添加索引后）。
规范化或非规范化（或者两者的结合！），通常也是提高采矿作业期间性能的可行想法。
关于mysql - MySql中的大表和分析，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1794232/