自1996年以来我一直在使用SQL，因此我可能会有所偏见。我已经广泛使用MySQL和SQLite 3，但也使用了Microsoft SQL Server和Oracle。
我见过的使用Pandas进行的绝大多数操作都可以通过SQL轻松完成。这包括过滤数据集，选择要显示的特定列，将函数应用于值等等。
SQL具有优化器和数据持久性的优点。SQL还具有清晰易懂的错误消息。Pandas的API有点晦涩难懂，在某些情况下，有时需要使用单个[ stuff ]，[[ stuff ]]有时需要使用.loc。熊猫的复杂性部分是由于存在如此多的超载而造成的。
所以我试图了解为什么熊猫如此受欢迎。
Answers:
真正的第一个问题是，为什么人们比单纯的SQL抽象更能使用DataFrame抽象。
TLDR；SQL不适合（人）开发和调试过程，而DataFrames则适合。
主要原因是，DataFrame抽象允许您构造SQL语句，同时避免冗长且难以理解的嵌套。编写嵌套例程，将其注释掉以进行检查然后取消注释的模式将由单行转换代替。您可以自然地在一个repl中逐行运行内容（甚至在Spark中）并查看结果。
请考虑以下示例：向表中添加一个新的转换后的（字符串错列的列），然后对其进行分组并进行一些聚合。SQL变得非常丑陋。熊猫可以解决此问题，但在涉及真正的大数据或特定分区（也许最近有所改进）时会丢失一些东西。
DataFrames应该被视为SQL例程的高级API，即使使用熊猫它们也根本不提供给某些SQL规划人员。
-
您可能会对此进行很多技术讨论，但是我在考虑以下用户角度。
您可能会看到关于Pandas数据处理而不是SQL的更多问题的一个简单原因是，按照定义，使用SQL意味着使用数据库，而如今的许多用例仅需要一些数据来存储“一劳永逸的任务（来自.csv，Web API等）。在这些情况下，从数据库进行加载，存储，操作和提取是不可行的。
但是，考虑到用例可以使用Pandas或SQL证明其合理性的情况，您肯定是没有错的。如果您想执行许多重复的数据操作任务并保留输出，我总是建议您首先尝试通过SQL。从我所看到的原因来看，即使在这些情况下，许多用户也无法通过SQL的原因有两个方面。
首先，pandas相对于SQL的主要优势在于它是更广泛的Python领域的一部分，这意味着我可以一口气加载，清理，操作和可视化我的数据（甚至可以通过Pandas执行SQL ...）。另一个很简单，就是所有太多的用户都不知道SQL功能的范围。每个初学者都将学习SQL的“提取语法”（SELECT，FROM，WHERE等），作为将数据从DB传递到下一个位置的一种方法。有些人可能会选择一些更高级的分组和迭代语法。但是在那之后，在您寻求专家（DBA，数据工程师等）之前，知识上往往会有相当大的差距。
tl; dr：通常取决于用例，便利性或关于SQL功能范围的知识空白。
在这两件事的应用中，有很多重叠之处，这是将苹果与橘子进行了比较。
pandas是使用通用编程语言Python实现的数据分析工具包。SQL是用于查询关系数据的特定于域的语言（通常在关系数据库管理系统中，例如SQLite，MySQL，Oracle，SQL Server，PostgreSQL等）。
SQL暗示
*值得强调的事实是，SQL是特定于域的，因此与使用越来越常见的关系数据库（例如NoSQL数据库）替代品的关系变得不那么重要了。这代表了数据存储和结构方式的根本转变，并且确实没有像旨在实现的SQL标准化开发那样普遍通用的访问方式。
另一方面，Python（pandas是相当“ pythonic”的，因此在这里适用），它是灵活的，可供来自不同背景的人们使用。它可以用作“脚本语言”，功能性语言和功能齐全的OOP语言。熊猫内置了可视化功能和数据源互操作性，但是您可以自由地将Python可以做的任何事情整合到您的工作流中（这是大多数事情）；科学的Python生态系统如雨后春笋般涌现，其中包括功能强大的工具（如Jupyter Notebook）和基本的scipy库，如matplotlib和numpy（熊猫在此基础上构建）。熊猫数据分析的重要元素是R启发，您通常不会发现统计学家会抱怨他们是否使用R（或者可能越来越多的熊猫！），而不是将所有内容都放入数据库并用SQL编写分析。
我并不是说熊猫比SQL更好，反之亦然，但是SQL是一个非常特定于域的工具，而熊猫是庞大，灵活且可访问的生态系统的一部分。我使用地理空间数据系统，其中关系数据库是重要组成部分，而SQL是功能强大且必不可少的工具。但是，熊猫是我日常工具包中同样重要的部分，即使不是更重要的部分，SQL通常也只能用于获取数据（可能需要进行一些预处理），因此我可以在熊猫中进行处理。
首先，熊猫不是那么受欢迎。我同时使用熊猫和SQL。首先，我尝试了解该任务-如果可以在SQL中完成，则我更喜欢SQL，因为它比熊猫更有效。尝试处理大数据（10,000,000 x 50）。尝试在SQL和熊猫中执行一些groupby操作。你会明白的。
我在使用pandas时很方便-就像将一列值拆分为一个数组并对其进行处理（例如从该数组中仅选择一些值）。现在，这种任务相对难以用SQL进行编码，但是熊猫可以简化您的任务。
我是即使我知道我的SQL也会在每种情况下都使用R的dplyr（语言，不一定是工具）的人之一。
我在Pandas / dplyr / data.table管道中看到的主要好处是操作是原子的，可以自上而下地读取。
在SQL中，您需要解析整个脚本，四处跳动（正在汇总什么内容，正在加入什么内容以及如何-左？内部？对吗？是否应用了任何过滤器？）以完全掌握正在发生的情况。
在Pandas等人中，流水线的每个步骤都是独立的，它对输入数据执行某些操作并返回输出数据，由于每个操作都有一个明确定义的状态，而不是仅仅处于打开状态，因此此顺序过程使人们更容易推断发生了什么查询级别。
是的，您可以执行WITH语句等，但是它需要更多的代码，并且与管道相比，尚不清楚正在使用的对象。
我是Pandas / Python的新手，但是有20多年的SQLServer DBA，架构师，管理员等职位。我爱Pandas，并且我一直在努力让自己在Pandas上正常工作，然后再回到自己的办公室，舒适的SQL世界。
为什么RDBMS更好： RDBMS的优势在于他们多年优化查询速度和数据读取操作的经验。令人印象深刻的是，他们可以做到这一点，同时平衡优化写入速度和管理高度并发访问的需求。有时，在简单的单用户用例中，这些额外的开销会使Pandas受益。但是即使那样，经验丰富的DBA仍可以调整数据库，使其在读取速度上优于写入速度上得到高度优化。DBA可以利用诸如优化数据存储，战略性磁盘页面大小调整，页面填充/填充，数据控制器和磁盘分区策略，优化的I / O计划，内存中数据固定，预定义执行计划，索引，数据压缩之类的优势， 还有很多。许多熊猫开发者给我的印象是，他们没有 不了解那里可用的深度。我认为通常会发生的事情是，如果Pandas开发人员从来没有足够大的数据来需要这些优化，那么他们就不会欣赏有多少时间可以节省您的时间。RDBMS世界在优化此功能方面拥有30年的经验，因此，如果需要大型数据集上的原始速度，则可以击败RDBMS。
为什么Python / Pandas更好： 就是说，速度不是决定一切的因素，在许多情况下也不是决定因素。这取决于您如何使用数据，是否共享数据以及是否关心处理速度。RDBMS的数据结构通常更严格，给开发人员增加了确定数据形状的负担。熊猫让您在这里更加放松。另外，这是我最喜欢的原因，您使用的是真正的编程语言。编程语言为您提供了更大的灵活性，可以将高级逻辑应用于数据。当然，还有丰富的模块生态系统和SQL无法接近的第三方模型。能够从原始数据一直到一个代码库中的Web演示或数据可视化都非常方便。它也更加便携。您几乎可以在任何地方（包括公共笔记本电脑）运行Python，这可以扩大结果范围，从而更快地吸引人们。数据库在这方面并不擅长。
我的建议？ 如果您发现自己要毕业于越来越大的数据集，那您就应该大胆尝试并了解RDBMS可以如何提供帮助。我已经看到百万行多表联接，汇总的汇总查询从5分钟调整为2秒。对工具带的这种了解只会使您成为更全面的数据科学家。您今天也许可以在Pandas中做所有事情，但是有一天您可能会分配RDBMS是最佳选择。
df.describe()df['population'].plot(kind='hist')df.to_csv('foobar.sv')。当您想向想要使用Excel的企业主展示一些东西时，这一点很重要。而且有df.to_excel也。但是在SQL中，您可以做到SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;（谢谢，vy32！）SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table; 见dev.mysql.com/doc/refman/8.0/en/select-into.html
我想提及的这些答案中唯一未提及的是，它还取决于您如何使用SQL。以arcpy为例。由于某些原因，arcpy.da函数均没有执行多次功能。这真的很奇怪，因为几乎所有其他python sql库都这样做。arcpy.da函数中的Where语句也限于大约120个字符。从本质上讲，这意味着如果您要对数据库进行大量处理，唯一的选择就是多次调用所选的arcpy.da函数，并在每次操作时更改where语句。您可以使用一些技巧来加快此过程的速度-例如，可以遍历数据集的各个部分-但实际上，这些技巧中的每一个都比仅使用一个arcpy.da慢得多。searchcursor将整个表加载到pandas数据框中，然后使用pandas，numpy和（如果您的数据确实如此庞大）操纵它。我在这里需要强调的是，在这种情况下，熊猫不仅速度更快。令人反感的更快。速度如此之快，以至于我一直在嘲笑自己不早做。使用大熊猫将一个脚本的执行时间从一个多小时减少了-我忘了这是从3.5个小时还是从1.5个小时跳到了12分钟。速度如此之快，以至于我一直在嘲笑自己不早做。使用大熊猫将一个脚本的执行时间从一个多小时减少了-我忘了这是从3.5个小时还是从1.5个小时跳到了12分钟。速度如此之快，以至于我一直在嘲笑自己不早做。使用大熊猫将一个脚本的执行时间从一个多小时减少了-我忘了这是从3.5个小时还是从1.5个小时跳到了12分钟。
需要注意的一件事是，尽管我可以使用sql完成此操作，但要花更多的时间来学习。我要么不得不专门学习Access中sql的操作-那就是该脚本数据的最终结果--Access中的sql并不像我实际想做的那样健壮-或我将不得不将所有数据写入sqlite3数据库，在那里进行操作，然后将其放入Access中。尽管这可能给我带来类似的性能结果，但将来会使我的脚本更难修改。
是的，有时是Pandas绝对比使用您可以使用的sql选项要好。我在sql中需要做的所有事情都是通过pandas中的函数完成的。如果需要，还可以将sql语法与pandas一起使用。没有理由不同时使用pandas和sql。
关于Pandas和numpy，我想说的一件事是，这两个库都是基于集合的方法。您可以遍历这些框架的数据框和系列构建，但实际上很难像这样修改这些结构中的数据，因此最终您将要用这两个库编写更高效的代码（基于集合），因为这样做非常容易做。对于SQL而言，如果不是被“引导”到不能使用基于集合的方法的话，这不是我所经历的。
我忘了跟熊猫提一件事。钱。熊猫是许多数据科学工作都希望您知道如何使用的工具。我看过的几乎每个数据科学工作都比数据库管理类型的工作支付更多的钱。我注意到的唯一例外是在数据工程领域，但我看到的职位很少。熊猫看起来一眼就能赚到更多钱。
我将根据自己的经验尝试回答这个问题。与其他答案相反，我更喜欢Sql深度学习和大数据相关的东西。有许多原因。正如可以看到这里，
Pandas提供了对表格数据的直观，强大且快速的数据分析体验。但是，由于Pandas仅使用一个执行线程，并且要求所有数据一次存储在内存中，因此无法很好地扩展到超过千兆字节规模的数据集。
SQL引擎通常将键或特殊列保留在数据结构（例如树）中，以促进CRUD操作。此数据结构保留数据库中所有数据的状态。熊猫无法做到这一点，因为它无法同时访问所有数据。另一方面，即使使用read_csv中的块参数，它也无法执行某些操作。例如，您无法对内存无法容纳的大型数据集进行直接批处理操作。依赖于整个数据集的任何其他任务都需要额外的编码。所有这些都可以在Sql中进行处理，而无需额外的编码，只需一个简单的查询即可。只需使用简单的Sql操作，而无需担心内存。
另一个区别是Sql中的CRUD操作可以与不同的授权策略一起应用，这在熊猫中是不可能的。
这并不是说哪个更好，这完全取决于您的任务。对于大规模计算，我更喜欢Sql，对于小型计算，我更喜欢熊猫。
大熊猫还没有其他一些事情，它们对于快速体验数据提取非常重要，我将在后面提到。现在，只需在这里看看。
并非完全是这个问题的答案，但是由于我本人是来这里寻找实际应用中的差异的：
https://pandas.pydata.org/pandas-docs/stable/getting_started/comparison/comparison_with_sql.html